Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation:
This issue is to implement Field Translations support (i.e. support for the entity translation module).
Proposed resolution:
See the attached patch that adds support for field translation. Latest patch: #1344672-437: Field Collection: Field translation (entity_translation) support..
Current Status:
Some users report the latest patch works, so long as you do not make all levels of a nested collection translatable. Users are cautioned that data loss has been reported -- please test carefully.
Remaining tasks:
There are some issues with the patch that need to be fixed. (See comments for details):
- #1344672-420: Field Collection: Field translation (entity_translation) support.: Update hook may delete existing data.
- #1344672-442: Field Collection: Field translation (entity_translation) support.: Problem with nested field collections.
Comments
Comment #1
Sborsody CreditAttribution: Sborsody commentedEntity translation doesn't seem to really work yet. See #1366220: Field collection translatable Field language for setHostEntity.
Comment #2
klonosWhen I try to enable entity translation for the "Field collection item" (under
/admin/config/regional/entity_translation
), I get these errors: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?
Comment #3
klonosApplying the patch from #1366220-4: Field collection translatable Field language for setHostEntity doesn't fix the errors I mention above.
Comment #4
heretic381 CreditAttribution: heretic381 commentedAny news for this issue?
Comment #5
mducharme CreditAttribution: mducharme commentedCan 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.
Comment #6
dshields CreditAttribution: dshields commentedSounds like a great idea to me!
Comment #7
plachYes, I've been considering something like that for a while. I've just had no time to work on it yet...
Comment #8
ayushjn CreditAttribution: ayushjn commentedThe 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.
Comment #9
dreizwo CreditAttribution: dreizwo commentedThanks 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...
Comment #10
inolen CreditAttribution: inolen commentedToday 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.
Comment #11
carn1x CreditAttribution: carn1x commentedPatch in #8 doesn't apply to latest stable or dev for me.
Comment #12
bforchhammer CreditAttribution: bforchhammer commentedNW 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.
Comment #13
malberts CreditAttribution: malberts commentedPreliminary support for entity_translation.
The specific use case where I tested:
A bean entity containing an unlimited field_collection field.
The bean is translatable but the field_collection field is not.
The field_collection_item entity for that field is translatable.
In this scenario you can translate whatever is on the bean but the values (entity ids) for the field_collection field are shared between translations. These field_collection entities are translated when viewing the admin page of the bean. The field_collection field is set to display as "Field collection items" which renders links for each item.
Example:
On the host entity:
field1: [en]="text", [es]="texto
field2: [und]=collection(id1, id3, id5)
collection_id1: ...translations...
collection_id3: ...translations...
collection_id5: ...translations...
There is another scenario which people might want based on UX where the field_collection fields are translatable with the intent of doing the field_collection_item translations at the same time as translating the host entity. However, technically this is an incorrect usage (for that purpose).
Example:
On the host entity:
field1: [en]="text", [es]="texto
field2: [en]=collection(id1, id3, id5), [es]=collection(id2, id4, id6)
This is because you are actually allowing a different collection per language. There might be valid cases where you would want to allow different collections per language where you do (not) want to have translations of the field_collection_items themselves. I did not address that scenario in this patch, but it might be related to #1865244: Allow multiple translation handlers on the same form
This patch adds
- default paths for field_collection_items
- entity_translation support
- paths for Devel output
- 'Translate' link when displaying field collection as "Field collection items"
- #1683784-42: Field Collection entities are untranslatable because they do not define valid base path
I am not sure if there are also entity_translation issues that we need to look at for this.
Comment #15
malberts CreditAttribution: malberts commentedTrying a differently generated patch, otherwise I'm not sure what that failure means.
Comment #17
malberts CreditAttribution: malberts commentedComment #18
klonos...coming from #1683784: Field Collection entities are untranslatable because they do not define valid base path
Comment #19
eristoddle CreditAttribution: eristoddle commentedThat 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
Comment #20
malberts CreditAttribution: malberts commented@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.
Comment #21
broonThanks 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:
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
Comment #22
malberts CreditAttribution: malberts commented@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.
Comment #23
cossimo CreditAttribution: cossimo commented@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.
Comment #24
malberts CreditAttribution: malberts commented@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.
Comment #25
cossimo CreditAttribution: cossimo commented@malberts: Much obliged. This is very helpful!
Comment #26
broonHey 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.
Comment #27
cossimo CreditAttribution: cossimo commentedI've been playing with the #17 patch, and it seems to work well, except for strange behavior when I try to add multiple sets of values.
For example, let's say I have a content type with field collection Xn, which is set to accept unlimited values and for which translatability is disabled. Within field collection Xn, there are several associated fields (let's say Xnx, Xny, and Xnz), all of which are set to translatable.
If I add one set of values to field collection Xn and save it, everything works fine. The values are appear on the node, in any views I create using the fields, etc. And all the subfields Xnx, Xny, and Xnz can be translated with no problems.
The hitch comes when I try to add multiple values for field collection X. For example:
Field Collection Xn
-X1
--X1x
--X1y
--X1z
-X2
--X2x
--X2y
--X2z
-X3
--X3x
--X3y
--X3z
etc...
Each time subsequent sets of values are added on the node edit page (for example, X2 and all its subvalues), the previous values (X1x, X1y, X1z) disappear. They don't necessarily disappear from the database because if you (have not made any of the subfields required and can) save the node, all the values appear correctly (on the node page and in any views). However, they do not appear when editing the node -- or I guess more accurately, they appear and disappear in different patterns as new values are added.
I have noticed some duplication in views when displaying translated subfields, but have not delved far enough in to this yet to see whether setting up field language filters or adjusting the query settings will have an effect .Edit: This views duplication can indeed be handled with field language filters and setting query settings to distinct.Comment #28
bdecarne CreditAttribution: bdecarne commentedmalberts, your patch #17 saved my life. Field collection is a very good module, support for ET is criticial.
Comment #29
csedax90 CreditAttribution: csedax90 commentedthe path doesn't work for me... how can i configure my node type and all fields of field collection to work together?
Comment #30
steinmb CreditAttribution: steinmb commented@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 :)
Comment #31
csedax90 CreditAttribution: csedax90 commentedThe 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
Comment #32
appzella CreditAttribution: appzella commentedI 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
Comment #33
appzella CreditAttribution: appzella commentedI run the patch again, it seems to work now.
Comment #34
malberts CreditAttribution: malberts commentedFor 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.
Comment #35
jmuzz CreditAttribution: jmuzz commented#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.
Comment #37
jmuzz CreditAttribution: jmuzz commentedMy 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.
Comment #38
jmuzz CreditAttribution: jmuzz commentedProbably 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?
Comment #39
jmuzz CreditAttribution: jmuzz commentedOh I get it I have to set the status. Guess I didn't really have to upload it again either.
Comment #40
dan.munn CreditAttribution: dan.munn commentedYour 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.
Comment #42
dan.munn CreditAttribution: dan.munn commentedApologies, did not spot that the previous patch generation contained errors :/
Comment #43
murtza CreditAttribution: murtza commented#42: field_collection-17_and_37_complete_2-1344672-42.patch queued for re-testing.clicked by mistakeComment #44
plachI am working on this.
Comment #45
plachHere 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.
Comment #46
zeno129 CreditAttribution: zeno129 commentedI am having an issue related to the patch included above.
I posted the details here: https://drupal.org/node/2059763
Comment #47
interdruper CreditAttribution: interdruper commentedI 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.
Comment #48
plach@zeno129:
Please don't open bug reports for code that has not been committed yet, let's stay focused here.
@interdruper:
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?
Comment #49
plachCopying the bug report from #2059763: Unable to translate a field collection when translating the parent node:
Comment #50
plachThe 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?
Comment #51
mavrom CreditAttribution: mavrom commentedI 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
Comment #52
acrollet CreditAttribution: acrollet commentedFor reference - the patch in #51 is from #1316162: Support content translation and host entity cloning
Comment #53
acrollet CreditAttribution: acrollet commentedI 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.
Comment #54
klonos#1865244: Allow multiple translation handlers on the same form was committed btw ;)
Comment #55
adinac CreditAttribution: adinac commented@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.
Comment #56
plach@adinac:
Well there are many use cases, but I guess the most common is leaving the field_collection field untranslatable and making the "Field collection item" entity type translatable in the Entity Translation settings. Obviously at least one field on the field collection item needs to be translatable.
You need the latest ET dev release.
Comment #57
klonosWell, 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).
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.
Comment #58
adinac CreditAttribution: adinac commentedI have a translatable entity with a field collection field with unlimited values. The field collection entity is translatable, it also contains some translatable fields and the field collection field on the host entity is left untranslatable.
The translation of the field collection on the host entity form works ok but i noticed that when creating the entity, the first time you click on the "Add another item' button and there is a single element for the field the translatable fields on the field collection lose their values. I couldn't figure out why this happens yet. Did anyone else ran into this problem? Some possible fixes?
Thanks.
Comment #59
Maico de Jong#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.
Comment #60
Cyclodex CreditAttribution: Cyclodex commentedHy 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:
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 :
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...
Comment #61
fagoThat'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.
Comment #62
fagoComment #63
plachIIRC 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.
Comment #64
jmuzz CreditAttribution: jmuzz commentedI 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)
Comment #66
jmuzz CreditAttribution: jmuzz commentedOh 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.
Comment #67
Pere OrgaI see an extra line in patch #66:
Comment #68
Pere OrgaI'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.
Comment #69
agoradesign CreditAttribution: agoradesign commentedThe anonymous function in the following line of the patch breaks PHP 5.2 compatibility:
edit: just saw that comment #60 mentioned that already and explained the problem in a very detailled way
Comment #70
agoradesign CreditAttribution: agoradesign commentedI'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:
the second line must be of course:
Actually, it is not real bug, but another PHP 5.3 construct, which is indeed not necessary to write this shorthand form
Comment #71
plachI 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...
Comment #72
jmuzz CreditAttribution: jmuzz commentedAdded suggestions from #60, #67, and #70.
About #60, is there some reason asort($operations) wouldn't work?
Comment #73
jmuzz CreditAttribution: jmuzz commentedComment #75
plachComment #76
Pere OrgaAfter 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...
Comment #77
agoradesign CreditAttribution: agoradesign commentedCaution! The patch from #72 is accidentially reverting this commit: http://drupalcode.org/project/field_collection.git/commit/0fd332e
Comment #78
agoradesign CreditAttribution: agoradesign commentedI 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 :)
Comment #79
jmuzz CreditAttribution: jmuzz commentedWhoops. Fixed #77.
I agree about the usability issues, they should be fixed as well.
Comment #80
mahmost CreditAttribution: mahmost commentedComment #81
jmuzz CreditAttribution: jmuzz commentedI 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.
Comment #82
jmuzz CreditAttribution: jmuzz commentedI'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:
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.
Comment #83
jmuzz CreditAttribution: jmuzz commentedIt 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.
Comment #84
jmuzz CreditAttribution: jmuzz commentedI 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.
Comment #85
jmuzz CreditAttribution: jmuzz commentedI 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.
Comment #86
StephenN CreditAttribution: StephenN commentedIn 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.
Comment #87
jmuzz CreditAttribution: jmuzz commentedHere is a version of the patch that handles recursive field collections better. It fixes the problem mentioned in #85 as well as some other issues that spring up with nested field collections. A similar solution may be able to solve #1837394: Nested field collection content not showing in edit page.
ALSO
#72 and #79 reverted this commit:
http://drupalcode.org/project/field_collection.git/commit/a666cce9
If you applied either #72 or #79 then please also apply this commit. The patch I am including now does not have this issue, but the interdiff does not apply the fix for it if you had applied #72 or #79.
Comment #89
jmuzz CreditAttribution: jmuzz commentedSame changes from #87 applied to unmodified 7.x-1.x
Comment #90
jmuzz CreditAttribution: jmuzz commentedComment #91
klonos@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 ;)
Comment #92
jdanthinne CreditAttribution: jdanthinne commentedPatch #89 works fine for me.
Comment #93
Rhodungeon CreditAttribution: Rhodungeon commentedjdanthinne 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.
Comment #94
jdanthinne CreditAttribution: jdanthinne commentedEntity 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"?
Comment #95
Rhodungeon CreditAttribution: Rhodungeon commentedThanks 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
Comment #96
steinmb CreditAttribution: steinmb commentedAll patches need to be applied against latest dev. version (7.x-1.x-dev), not latest stable.
Comment #97
Rhodungeon CreditAttribution: Rhodungeon commentedThanks!
Comment #98
Rhodungeon CreditAttribution: Rhodungeon commentedTested 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?
Comment #99
Darren Clark CreditAttribution: Darren Clark commentedPatch #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.
Comment #100
thehyperlink CreditAttribution: thehyperlink commentedDuplicate 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
Comment #101
Darren Clark CreditAttribution: Darren Clark commentedWith 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.
Comment #102
jmuzz CreditAttribution: jmuzz commented@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.
Comment #103
jmuzz CreditAttribution: jmuzz commentedComment #104
Darren Clark CreditAttribution: Darren Clark commented@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.
Comment #105
Darren Clark CreditAttribution: Darren Clark commented@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.
Comment #106
areke CreditAttribution: areke commentedComment #107
mcardin CreditAttribution: mcardin commentedTested patch #89.
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.
Comment #108
Darren Clark CreditAttribution: Darren Clark commentedI've now got the following working:
- Translating a field_collection now is a separate entity, updating does not affect the original
- Cloning a field collection works correctly
- Field collections inside field collections also is translating and cloning correctly.
When setting up the field collection for localisation do not set enable translation on all the fields inside the collection but only on the field collection itself.
A patch is attached in order to create I've used references from:
https://drupal.org/node/1316162
(Implemented https://drupal.org/files/field_collection-1316162-192.patch which is used for cloning nodes)
Translating fields issue (Martin's Blog):
http://theduttons.org/?p=7
Issues:
- On translating multi level field collection forms there can be warnings from field_widget_instance and field_widget_field, these have been suppressed for now however further investigation to clean this.
- Setting the item_id to empty causes an entity warning.
entity/includes/entity.controller.inc
To suppress then this needs modifications to change if ($entity->is_new) { to if (@$entity->is_new) {
Comment #109
jmuzz CreditAttribution: jmuzz commented@darren
The purpose of entity translation is to allow people to choose which fields in an entity can be translated, with the rest of them being shared so that updating them effects every translation. Creating separate entities for each translation is "node" or "content" translation. The thread you referenced is the place for getting node translation working. Please only post patches in this thread that help to get entity translation working.
Comment #110
Darren Clark CreditAttribution: Darren Clark commented@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.
Comment #111
jmuzz CreditAttribution: jmuzz commented@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.
Comment #112
Darren Clark CreditAttribution: Darren Clark commented@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.
Comment #113
jmuzz CreditAttribution: jmuzz commented@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.
Comment #114
ddrozdik CreditAttribution: ddrozdik commentedHi guys,
What status of this issue? I tried to use your patches with dev version of module but they don't work properly.
Comment #115
jmuzz CreditAttribution: jmuzz commented89: field_collection-et-1344672-89.patch queued for re-testing.
Comment #116
jmuzz CreditAttribution: jmuzz commentedDid 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.
Comment #117
Darren Clark CreditAttribution: Darren Clark commented@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.
Comment #118
mcardin CreditAttribution: mcardin commented@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
Comment #119
Andrey Inkin CreditAttribution: Andrey Inkin commented@Darren Clark
Patch #108 worked for me (thanks!), but same error as described @mcardin
Just inserting
$entity->is_new = FALSE;
right after
$entity->save(TRUE);
should do the trick.
Because 'EntityAPIController::save($entity)' unsets 'is_new' flag, it's ok to set it again (since we are in 'presave' hook and know that $entity->is_new will be used again).
Comment #120
egontinno CreditAttribution: egontinno commentedPatch #108 worked for me + #119 suggestion.
Comment #121
mcardin CreditAttribution: mcardin commentedYes it works for me too. Patch #108 and #119 correction
Comment #122
mbe1980 CreditAttribution: mbe1980 commentedHi,
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:
But the error described at #118 isn't gone.
Do you have any hints for me?
Thanks!
Comment #123
Rhodungeon CreditAttribution: Rhodungeon commentedI've applied patch #89 and I can't modify a translated node with field collection fields.
The error that gives me is
...
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!
Comment #124
jmuzz CreditAttribution: jmuzz commentedMy 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.
Comment #125
Rhodungeon CreditAttribution: Rhodungeon commentedThanks for the tips!
It worked! I've applied patch 89-2 and later 108.
Thank you so much!
Comment #126
andrezstar CreditAttribution: andrezstar commentedMe on the other hand still trying to apply those two patches ( with win7. 89-2 and then 108)
Tried:
-GNUwin32
-TortoiseSVN
and not working. Help plz?
Comment #127
Darren Clark CreditAttribution: Darren Clark commented@Andrey Thank you for the entity updates to prevent the warning message.
I've incorporated this change into a new patch against 7.x-1.x:
https://drupal.org/files/issues/field-collection-et-1344672-108-v2.patch
In addition for anyone having issues applying the patch such as @andrezstar attached is the patched module:
https://drupal.org/files/issues/field_collection-1344672-108-v2.tar_.gz
Comment #128
andrezstar CreditAttribution: andrezstar commentedthanks 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
Comment #129
Darren Clark CreditAttribution: Darren Clark commented@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.
Comment #130
yaoweizhen CreditAttribution: yaoweizhen commented@Darren
Patch still doesn't work well, so I uploaded patched 89-2 and 108v2 module files.
Patch 89-2 lost includes/translation.handler.field_collection_item.inc file from 89. Patch 108v2 always failed. I compared and changed manually.
BTW, If you get error when node submit, please check this issue https://drupal.org/node/2141781
Comment #131
Nick Robillard CreditAttribution: Nick Robillard commentedI'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!
Comment #132
jmuzz CreditAttribution: jmuzz commentedThe 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.
Comment #133
jmuzz CreditAttribution: jmuzz commentedTry 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.
Comment #134
Nick Robillard CreditAttribution: Nick Robillard commentedAh 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.
Comment #135
kumkum29 CreditAttribution: kumkum29 commentedHello,
Have you planned to include #89 and #108 patch in the next dev version?
Thanks.
Comment #136
jmuzz CreditAttribution: jmuzz commented#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.
Comment #137
smithworx CreditAttribution: smithworx commented89: field_collection-et-1344672-89.patch queued for re-testing.
Comment #138
donquixote CreditAttribution: donquixote commentedThis works for me, but only with the latest entity_translation-7.x-1.x from 2014-Jan-22.
Instructions:
- Create a node type with a field_collection field.
- Enable entity_translation for the node type.
- The field_collection field itself should NOT have translation enabled.
- Visit admin/config/regional/entity_translation
- In "Translatable entity types", tick the checkbox for "Field collection item".
- Visit admin/structure/field-collections/*/fields(/*)
- Create some fields, and enable translation for some of them.
EDIT: Here is the link,
https://github.com/donquixote/drupal-field-collection/compare/7.x-1.x-en...
Comment #139
jmuzz CreditAttribution: jmuzz commentedSounds good. Does #138 change something, or is it like a reroll for the latest entity_translation ?
Comment #140
donquixote CreditAttribution: donquixote commented@jmuzz:
The first commit is just #101. The second commit is something additional.
I did not look further than #101, because this was the last green patch.. maybe I missed something.
Comment #141
lukusHi - can anyone provide an update on this issue. I'd be happy to review any patches if necessary. Is patch #101 the latest?
Thx.
Comment #142
donquixote CreditAttribution: donquixote commentedThere are some "solutions" on github. I used one of them for #138, but I don't remember which.
https://github.com/phreaknerd/drupal-field-collection
https://github.com/ribel/drupal-field-collection
It would be great if those people could get over here and help us out :)
But it would also be great if the Drupal community would stop doing patches and start doing pull requests.
Comment #143
jmuzz CreditAttribution: jmuzz commentedPlease 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.
Comment #144
jussil CreditAttribution: jussil commentedIf 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:
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.
Comment #145
afi13 CreditAttribution: afi13 commentedHi guys,
What status of this issue?
Comment #146
jmuzz CreditAttribution: jmuzz commentedHi 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.
Comment #148
donquixote CreditAttribution: donquixote commented@jussil (#144)
I think we should agree on *one* supported way to make field collections field-translatable.
Imo, the field_collection field itself should *not* be ticked as field-translatable.
Instead, the fields on the field collection item entity should be field-translatable. Unless this field is again a nested field collection field.
E.g.
Node type "page":
If we constrain the scenario like this, we have an easier job testing and supporting this stuff.
Comment #149
jmuzz CreditAttribution: jmuzz commentedI 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).
Comment #150
FreeAndEasy CreditAttribution: FreeAndEasy commented#149 Patch field_collection-et-1344672-89.patch works for me with newly created nodes (not cloned).
Comment #151
dshields CreditAttribution: dshields commentedFrom 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
Comment #152
jmuzz CreditAttribution: jmuzz commentedGood point, dshields, it should create a new field collection on the translations as well.
Comment #153
jmuzz CreditAttribution: jmuzz commentedNew field collections will now copy their translatable fields into the languages its host has translations for.
Comment #154
jmuzz CreditAttribution: jmuzz commentedComment #155
jmuzz CreditAttribution: jmuzz commentedA better version that doesn't save the field collection item an extra time.
Comment #156
dshields CreditAttribution: dshields commentedSorry, 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?
Comment #157
odegard CreditAttribution: odegard commented@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.
Comment #158
dshields CreditAttribution: dshields commentedno.
just one field collection.
Comment #159
jmuzz CreditAttribution: jmuzz commented@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.)
Comment #160
dshields CreditAttribution: dshields commentedI am using workbench moderation, yes.
Maybe that's the issue..
Comment #161
jmuzz CreditAttribution: jmuzz commentedI'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.
Comment #162
dshields CreditAttribution: dshields commentedI hadn't seen that issue - thanks jmuzz - I'll report back after testing!
Comment #163
dshields CreditAttribution: dshields commentedThanks 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.
Comment #164
Honza Pobořil CreditAttribution: Honza Pobořil commentedPatch #163 works for me but after save new translation it prints some notices:
Comment #165
mgiffordThat should be easy to fix... The patch probably is just missing two checks to verify that $field & $instance are variables.
Comment #166
jmuzz CreditAttribution: jmuzz commented@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.
Comment #167
jmuzz CreditAttribution: jmuzz commented@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?
Comment #168
colanWhen 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.
Comment #169
jmuzz CreditAttribution: jmuzz commentedI can confirm that language enabled nodes created before the patch is applied will break as described.
Comment #170
jmuzz CreditAttribution: jmuzz commentedI've added an update script that should fix the fields inside field collections that were using entity translation before the patch.
Comment #171
jmuzz CreditAttribution: jmuzz commentedAnother 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.
Comment #172
fagoNot really looked into the details, but here a first review: (mostly on style)
There should be a one line summary.
variable names should always be readable, even if longer.
Methods are named using CamelCase.
Useless params - either add descriptions or remove them.
Coding style - should start on new line.
Whitespace.
Whitespace.
Should be camelcased (As said) and misses docs.
Again readable varnames for t_field, $lang_code which usually is $langcode.
This is weird - cannot that be done without a global?
Comment #173
hyscaler CreditAttribution: hyscaler commentedLatest 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)
Comment #174
jmuzz CreditAttribution: jmuzz commentedNo it hasn't been fixed yet. The patch will need to be updated for the latest development version.
Comment #175
jackdaniel9 CreditAttribution: jackdaniel9 commentedentity translation 7.x.-1.x-dev
field_collection 7.x.-1.x-dev
ok I think I managed to understand
Apply patch #163
+
Exception: The host entity cannot be changed. in FieldCollectionItemEntity->updateHostEntity() (line 397 of D:\wamp\www\praxar\profiles\orizonmedia\modules\contrib\field_collection\field_collection.module).
Apply patch #108
+
- Setting the item_id to empty causes an entity warning.
entity/includes/entity.controller.inc
To suppress then this needs modifications to change if ($entity->is_new) { to if (@$entity->is_new) {
+
you must recreate all nodes
/***/
i have insert
class EntityTranslationFieldCollectionItemHandler extends EntityTranslationDefaultHandler
in
entity_translation/includes/translation.handler_factory.inc
(i didn't create file translation.handler.field_collection_item.inc because i had a error)
Comment #176
jmuzz CreditAttribution: jmuzz commentedComment #177
jmuzz CreditAttribution: jmuzz commentedRerolled and made the requested changes. Haven't done any testing other than the unit tests.
Comment #178
yingtho CreditAttribution: yingtho commentedWhen 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:
Comment #179
MantasK CreditAttribution: MantasK commentedI 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.
Comment #180
yingtho CreditAttribution: yingtho commentedI 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.
Comment #181
biswajeetparida CreditAttribution: biswajeetparida commentedAfter 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 theupdateHostEntity()
method.Please suggest.
Comment #182
biswajeetparida CreditAttribution: biswajeetparida commentedComment #183
keopxHi,
Using field_collection-et-1344672-177.patch works for me, but:
biswajeetparida07 said:
Only success when edit/update. When we created new translation work fine.
Modules and commit versions:
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.
Comment #184
jannis CreditAttribution: jannis commentedPatch 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
Comment #185
jmuzz CreditAttribution: jmuzz commentedInteresting point about the add button. The thing about entity translation is that any translated entity needs to exist in the default language before it can be translated. If your field collection field is not translatable but the field collection items inside it have translatable fields, then I don't know if there is a way around adding them to the default language.
Comment #186
jannis CreditAttribution: jannis commentedLingotek's newer versions of their module seems to support 'nested field collections' up to 10 levels deep. Lingotek
Looking into pulling some of their code into a custom module that adds that support
Comment #187
sylus CreditAttribution: sylus commentedDue to recent additions of hook_update_n in field_collection I had to update this patch to use field_collection_update_7007.
Setting to needs review to trigger testbot.
Comment #188
Heine CreditAttribution: Heine commentedWhy the exception? This prevents saving the edit form of translatable entities that have an untranslatable field collection. Prior behaviour would update the field collection in the source entity.
Comment #189
jmuzz CreditAttribution: jmuzz commentedIt is analogous to the exception that can be thrown in setHostEntity, since we are adding a new operation that could potentially change the value of an entity's field, it's important to make sure that that entity is actually the one hosting the Field Collection, sort of a sanity check. Perhaps there is a bug in the check. As long as the source entity as you describe it is the same as the entity being translated the exception shouldn't get thrown.
Comment #190
stevieb CreditAttribution: stevieb commentedI get a WSOD using the patch in #187
Comment #191
dshields CreditAttribution: dshields commented@stevieb - what error messages are in your logs when the page delivers WSOD?
Comment #192
stevieb CreditAttribution: stevieb commentedwhen applied to the current dev the WSOD disappears - I'm still unable to translate field collections on a working site
I'll try it with a clean install over the weekend
Comment #193
dshields CreditAttribution: dshields commented@stevieb - any php errors that you can find in your logs would help diagnose the issue
Comment #194
mahalo13 CreditAttribution: mahalo13 commented#177 solved the Problem https://drupal.org/node/1281974 but all items have the same language (en) and not the language of the translation.
Comment #195
NWOM CreditAttribution: NWOM commentedSadly #187 doesn't work. On the edit pages, it correctly shows the correct translated text. However, on the node pages, it only shows for my default language. The text for the other languages do not show at all.
Edit: This has been applied to the latest DEV.
Comment #196
trim108 CreditAttribution: trim108 commentedPatch that works for me. I used field_collection-7.x-1.x-dev and entity_translation-7.x-1.0-beta3 modules.
Comment #198
mgifford@trim108 - your patch is malformed. Not sure why. I think this is a fair representation of it based on the git repository though.
Comment #199
mgiffordComment #201
joseph.olstadMGifford, thanks for this, your patch applies correctly to the 2014-Apr-16 dev branch.
Comment #202
mgiffordShould it have been built on another branch?
Comment #203
joseph.olstadAll the test result says is:
Added field value is shown. Other field_collection.test line 258
Is there any way to view field_collection.test to see what test name:
is doing?
Where can we get a copy of field_collection.test to see what this test is doing?
Line 258 seems to be referring to the test file because line 258 in the patched .module is empty.
? any idea how to find out what this test is doing?
Comment #204
bmad CreditAttribution: bmad commentedwith regards to the et-2 patch (#198)
I have installed the patch manually and still no joy on the translating of fields. I switch to french and it looks like the entry of the data when translating a node works fine, but when you try and modify it after it's created, it seems to look at the wrong version or something...
I am tryign to perform the patch on field_collection-7.x-1.x-dev and I have the entity_translation-7.x-1.0-beta3 module alongside.
HELP! is there a new field_collection module build in the works? we've got a publish dedaline ion several weeks and we can't enter the content on the French side
Comment #205
Scott Robertson CreditAttribution: Scott Robertson commentedThe latest patch seems to work correctly when editing a node that already has an entity translation, but not when I try to create an entirely new entity translation.
If I inspect the name of the input element in my test field collection, it is:
field_test_collection[fr][0][field_test_sub_collection][en][0][value]
I believe the 'en' key should actually be 'fr'; if I save the new translation, I don't have any value for the French version of the field.
Comment #206
RaulMuroc CreditAttribution: RaulMuroc commentedIf I go to admin/config/regional/entity_translation, I got the following:
Image
Don't should be able to be choosen 'Field collection Field'? Do I miss something?
I can mark in 'manage fields 'of my content type the 'Field collection' as 'Enable translatable' but is no way to translate them (or at least I don't find).
I applied the latest patch in latest field collection dev.
Comment #207
jmuzz CreditAttribution: jmuzz commented#196: This is much smaller than the previous patch. Are we really sure the rest of the changes that #187 made aren't necessary? The updates were removed, the translation handler was removed, there are many hardcoded references to LANGUAGE_NONE that are no longer being replaced...
It might be better to go back to #187 as a basis for future work on this.
Comment #208
Scott Robertson CreditAttribution: Scott Robertson commentedI believe jmuzz is correct that more needs to be done than what is in #196. I was only able to start having more success with translations when I removed the hardcoded LANGUAGE_NONE references.
Comment #209
ciss CreditAttribution: ciss commentedAre there any tests that define the expected outcome(s)? I've only seen manual tests being mentioned in several comments, but no evidence of a test suite that could further a test driven approach to the problem.
Comment #210
jmuzz CreditAttribution: jmuzz commentedYeah I just tested it again and I really don't see what the problem is. To the people who are saying that it doesn't appear translated or it's just translating to english, make sure Field Collections are set to translatable in the entity translation module settings and that the fields are set up so the correct ones are translatable to achieve your desired results. For the WSOD, try doing a cache clear, the patch adds a file so the .info needs to be reread.
For the people looking for the test suite, field_collection.test is right there along with the rest of the field_collection.* files.
Comment #211
RaulMuroc CreditAttribution: RaulMuroc commentedField collection being translatable doesn't work fine with multiple values field, just with single value field.
Comment #212
RaulMuroc CreditAttribution: RaulMuroc commentedHere the image related to the previous post.
As you can see there is a link "add" to add a new value to the Field collection but the fact is that I already added before and inserted a value. But it keeps asking again and when click on 'add' it says "Too many items" due to it really exists. If I go to 'edit' the node it offers to modify the first value of Field collection but not the second one (like if it doesn't exist) and I cannot do anything else from here on.
Somebody with similar situation?
Comment #213
jmuzz CreditAttribution: jmuzz commented@RaulMuroc I tried testing this. I made a content type with a field collection and a translatable text field. I made a text field inside the field collection and made it translatable. I made an instance of the content type with a single value in the field collection. I added another value to the field collection using the add link on the view page, and it worked. I translated the text field in the first value, and that worked too.
Are you using patch #187 / #210 ? That's the one that's closest to working and any help reviewing that patch would be appreciated.
Comment #214
RaulMuroc CreditAttribution: RaulMuroc commentedIndeed I realised I had a site based on Content translation and I was trying to mix with Entity translation.
So finally I applied the other patchhere and everything is cool.
Sorry, I didn't notice at the beginning the mix of concepts.
BR
Comment #215
NWOM CreditAttribution: NWOM commentedThe patch appears to need a re-roll. Also, when attempting to manually apply the patch, I get a WSOD.
Comment #218
jmuzz CreditAttribution: jmuzz commentedHere's a version that should apply to 7.x-1.x again.
Comment #220
Scott Robertson CreditAttribution: Scott Robertson commentedUsing the patch in #216, I'm having issues with a multi-value field collection that's within another field collection. My setup is as follows:
- Content type (with field translation enabled) with field collection field (field_a)
- field_a has another field collection field attached to it (field_b)
- field_b is set up to allow multiple values and has a regular text field attached to it (field_c)
- Field Collections are set up to be translatable in the Entity Translation settings
- field_a, field_b, and field_c are ALL configured to be translation
When trying to translate a node, the edit form looks fine. I can see the original values in each field, however when I submit the form, I receive the following error:
Notice: Undefined offset: 1 in field_collection_field_widget_embed_validate() (line 1877 of ....../wwwroot/sites/all/modules/field_collection/field_collection.module).
Which is this line here:
elseif ($form_state['values'][$field_state['array_parents'][0]][$field_state['array_parents'][1]][$element['#delta']]) {
After doing some debugging, it looks like $element['#delta'] is set to 1, however there is no such index in $form_state['values']['field_a']['fr'], there is only an index of 0.
Note that this ONLY occurs if there is more than one value for field_b (AKA I have hit "Add more items"). If there is only one instance of field_b on my node, I don't get any errors.
Comment #221
Carlos Miranda Levy CreditAttribution: Carlos Miranda Levy commentedI get a WSOD when trying to edit nodes after applying the patch at #218.
My nodes have multiple values field, which is stated that the patch won't cover.
But just giving you a heads up because I wanted to use translation for a single value collection, but it shows WSOD when trying to edit any node that has a field collection.
I deleted the fields from the field collection and still get the WSOD, but nothing is written on the log.
Before removing the multiple value fields from the collection, I would get the following error when attempting to edit/add a node that included that field collection:
MESSAGE Notice: Undefined property: stdClass::$original in field_collection_field_update() (line 1040 of /xxxxxxx/sites/all/modules/field_collection/field_collection.module).
SEVERITY notice
I did clear cache via drush cc all at every step of my tests.
Comment #222
PaperWeight CreditAttribution: PaperWeight commentedPatching 7.x-1.0-beta7 with #218 results in Hunk #8 failing
EDIT:
Applying patch to 7.x-1.0-beta6+13-dev worked
Thanks stevieb
Comment #223
stevieb CreditAttribution: stevieb commentedpatch using the dev version
Comment #224
PaperWeight CreditAttribution: PaperWeight commentedI seeing the same issue as Carlos in #221 - I get the WSOD whenever I try to edit a node containing a field collection.
7.x-1.0-beta6+13-dev with the patch in #218
PHP error log shows:
PHP Fatal error: Call to undefined method EntityTranslationNodeHandler::addChild() in /path-to-www/sites/all/modules/field_collection/field_collection.module on line 1634
That relates to:
EDIT: More info
To reproduce, I'm just adding a field collection to a content type and make it translatable. I don't even need to add fields to that collection to get the WSOD when I try to add content of that type. Removing the filed collection from the content type brings everything back.
Comment #225
fxfx CreditAttribution: fxfx commentedinstalled dev version with #218 patch no errors in patching and no error in pages, i can now save translated field collection fields but does not appear at all in the localized version of the node
Comment #226
jwilson3Thanks for everyone's hard work on this issue -- amazing.
I have patch in #218 working with latest dev branch of the module, however, like comments #164 and #178, I am also receiving the following two warning messages (showing up multiple times for each group of fields in the field collection of the translated entity):
The messages are shown only once after saving the translation. Subsequent refreshes of the translated entity view page, cause no errors, which leads me to believe there is still some issue somewhere in some of the code that is introduced here.
Comment #227
mh86 CreditAttribution: mh86 commentedI rerolled patch from #218 with a small fix in EntityTranslationFieldCollectionItemHandler::getLanguage()
The current logic in getLanguage() assumed that a translatable host entity always exists. In my case I have a profile2, which is not marked as translatable, with translatable field collection items on it. With this scenario the source language was always set to the site's default language, regardless in which language the user entered the data. The attached patch fixes this by checking whether the host entity is translatable, if not, it's going to use the default implementation that is configured via the Entity Translation module (admin/config/regional/entity_translation). I was also wondering why we look for the host entity's language at all and not use the default implementation?
Comment #228
mh86 CreditAttribution: mh86 commentedUpdated patch that fixes a PHP warning in the changes from my last patch.
Comment #229
Lukas von BlarerI am having two issues with this patch:
1: When translating field collections that have translatable and untranslatable fields, the translatable ones have empty values and have to be re-entered.
2: Date fields inside multivalue field collection fields are not saved the first time when being translated except for the first value.
Comment #230
stewart.adam CreditAttribution: stewart.adam commentedI downloaded the latest dev release of field_collection and the applied patch from #228. I have setup a multi-value field collection containing an image field and a text area. Field translation (via entity translation) was enabled on all three.
I see the same issue as #226 - PHP warnings on the first edit, subsequent edits do not display errors. However, viewing the translated versions results in an empty page. I've debugged this and determined it is because Drupal cannot retrieve any deltas for the fields; after looking in the database I can confirm this and it looks like a bug in the patch.
After initially translating a node, I see a second row in the field table being added but under the same language as the source node.
For example, this is the contents of the image field's table (this field is included in the field collection):
field_collection_item field_slideshow 0 16 20 en 0 51 english title 2592 1728
field_collection_item field_slideshow 0 17 22 en 0 51 2592 1728
The second row should have been added with a 'fr' code, and its text column is empty when it shouldn't be.
Similar story with the caption field's database (also included in the field collection):
And some very unusual results for the field collection table itself:
----------------
edit: I have some additional follow-up to testing above. I deleted all nodes and ensured the tables for the 3 fields mentioned above were empty, then I disabled translation on the image and text fields but left translation enabled on the actual collection. Creating a new node then translating it resulted in redundant rows in the field collection table:
Comment #231
fromtheindia CreditAttribution: fromtheindia commentedI am also facing the same issue. I am using field_collection with multivalue. No success with the patch #228...
Comment #232
pbuyle CreditAttribution: pbuyle commentedThe attached patch is a re-roll of patch form #218 so it apply on current dev.
Comment #233
pbuyle CreditAttribution: pbuyle commentedThe attached patch is a re-roll of patch from #218 so it apply on current dev.Comment #234
pbuyle CreditAttribution: pbuyle commentedThe attached patch is a re-roll of patch from #218 so it apply on current dev.
Comment #235
alcroito CreditAttribution: alcroito commentedThe patch in #234 isn't a proper one, because it does not include the includes/translation.handler.field_collection_item.inc file, from 218.
Comment #236
alcroito CreditAttribution: alcroito commentedAttaching re-roll against git head, of patch #228.
Comment #237
alcroito CreditAttribution: alcroito commentedAttaching a new patch that I think fixes some problems regarding saving the form for the first time, and the values not being there, by using getFormLanguage() instead of getLanguage().
It also adds a check when deleting a field collection, because sometimes invalid ids are returned, which gives a fatal error trying to call delete on a non-object. So there is an underlying problem that is still not solved, but at least it doesn't throw the error for now.
Another check is added to check that an original object exists in the host_entity (FFPs for example don't have by default an original object).
To test this you have to do the following steps:
1) Download and enable latest DEV field_collection and entity_translation.
2) Apply the patch.
3) Clear cache just in case.
4) Go to admin/config/regional/entity_translation and Enable Translateable types for Field Collection Item and Node.
5) Go to a Node type configuration form, and enable Field Translation for it.
6) Add a field collection to the node type, and add some fields into it (text fields, images).
7) Enable Field translation for both the Field collection field, and the fields inside of it.
8) Create a node in default language (was English for me) and populate the field collection fields, save the node.
9) Go to translate tab, and add a translation (Spanish for me), the old values should be present in the FC form, and if you modify them and save the form, the new values should appear.
Personally I did more testing with FPPs + Field collections, rather than Node + Field collection, but to make it work for FPPs there is significant additional code required to be added to the FPP module.
Comment #238
england9911 CreditAttribution: england9911 commentedI've followed instructions in #237, but get an error when trying to create a node:
I've seen earlier in this thread people suggesting clearing cache to fix this issue, but that doesn't seem to help.
Any ideas?
Comment #239
alcroito CreditAttribution: alcroito commentedYes I have the same issue if applied in Drupal project, that is because the patch should be applied against root folder of field_collection. If applied in project root, for some reason the includes folder is created in Drupal root, rather than in the field collection folder.
So simply move the includes folder with the file, into the proper place under field_collection module.
Comment #240
england9911 CreditAttribution: england9911 commentedthe patch was definitely run against the root of field_collection. The translation.handler.field_collection_item.inc file was created there e.g:
field_collection/translation.handler.field_collection_item.inc
I've manually put it in:
field_collection/includes/translation.handler.field_collection_item.inc
And the error has gone away. Maybe this was a permissions problem - the patch file looks fine.
Comment #241
liquidcms CreditAttribution: liquidcms commentedfrom #237 above, is this correct:
isn't the goal here to enable field translation for the FC (or not, depending on how the patch works) and the fields inside it WHICH REQUIRE TRANSLATING?
Comment #242
liquidcms CreditAttribution: liquidcms commenteddeleted
Comment #243
liquidcms CreditAttribution: liquidcms commentedmy test:
- latest -dev
- patch from #237 (almost applied cleanly, 1 line i had to do manually)
node (set as ET)
- class (fc, field set as translatable)
-- timetable (textfield, set as translatable)
-- slot (fc, set as non translatable)
---- various fields all set as not translatable
- first thing i notice is that the non translatable fields within class no longer state "all languages"
- the non translatable fields seem to be fine, if i change 1, the change appears on both lang versions
- the translatable field does not work. it shows the latest entered value (from whichever lang ver) on the edit form for either lang and on the view of the node it shows on only the original language ver of the node
so basically, the 1 translatable field does not appear to be translatable and doesn't get created at all for the 2nd lang.
Comment #244
jmuzz CreditAttribution: jmuzz commentedThe updateHostEntity function was committed for #2013811: field_collection_field_update() saves old host entity and overwrites changes. This version of the et patch is the same except it doesn't add that function.
Comment #245
RaulMuroc CreditAttribution: RaulMuroc commentedSo this issue should be closed as duplicate?
Comment #246
jmuzz CreditAttribution: jmuzz commentedNo, that one function that was written for this patch had a use outside of adding entity translation and was needed to fix a critical bug. This issue still needs resolution for adding entity translation to field collections.
Comment #247
liquidcms CreditAttribution: liquidcms commentedmy bad..for #243.. i see now that the patch did not apply completely. the includes file does not get created. will create changes manually and retest.
- didnt help; will need to go through and apply whole patch manually to be sure other parts not missed.
Comment #248
xumepadismal CreditAttribution: xumepadismal commentedI've rerolled patch against latest dev.
Comment #249
jwilson3Shouldn't the
#access =>field_collection_item_is_translatable()
be on the$elements['translate']
instead of$elements['add']
Comment #250
joseph.olstadYes jwilson3 is correct, patch from #248 should be updated, the #access =>field_collection_item_is_translatable() should be on the $elements['translate'] instead of $elements['edit']
We're currently using field_collection 7.x-1.0-beta6+8-dev
with these patches:
- http://drupal.org/files/issues/field_collection-et-1344672-187.patch
- http://drupal.org/files/issues/field_collection-field_collection_uuid-20...
- http://drupal.org/files/issues/migration_field_collection-2298877-01.patch
and in our environment the #access =>field_collection_item_is_translatable() is on $elements['translate'] , not $elements['edit']
Otherwise people not using entity_translation would not be able to 'edit' . However those using 'entity_translation' will want to have the option to translate.
this is what I understand after reading the function field_collection_item_is_translatable()
Thanks,
Thanks
Comment #251
RaulMuroc CreditAttribution: RaulMuroc commentedSTATUS
PROBLEM
The original (so the first created) field collection is shown (for ex: german lang). But the translations of it are not shown (ex: slovenian, spanish, italian).
LOOK INTO THE CODE
In field_collection.module, line 1365 inside function hook_field_formatter_view , I apply dpm($display, "display type"), and the following is shown:
Original field collection
label (String, 5 characters ) above
type (String, 21 characters ) field_collection_list
weight (String, 1 characters ) 0
settings (Array, 7 elements)
module (String, 16 characters ) field_collection
For each translation field collection
label (String, 6 characters ) hidden
type (String, 21 characters ) field_collection_view
weight (String, 2 characters ) 21
settings (Array, 9 elements)
module (String, 16 characters ) field_collection
I don't understand why the "type" is different (that makes in this function to call different swith cases), and also why in translation 'label' and 'values' are hidden (but not empty, values are either here so in DB as well).
CONCLUSION
Looks like if it is a READ/UPDATE of view_mode problem, not CREATE problem (talking on CRUD terms) as the data exists.
Tried to fix but don't find the point (sorry about that).
Comment #252
sinasalek CreditAttribution: sinasalek commentedSTATUS
Latest dev field collection.
Applied patch #248
Fixed applying changes on #249
PROBLEM
I'm having the same problem as @RaulMuroc
I did a bit more investigation :
Upon saving the translation i encountered the following notice twice :
Note that it does not happen when saving the node with the field collection items at the first place and only happens when saving the translation.
I check the content of $field_collection var inside field_collection_field_formatter_view, in my case the problem is that the translation language is the original language for each translatable field :
Comment #253
sinasalek CreditAttribution: sinasalek commentedSeems that the following notice is unrelated :
It's caused by link widget
Comment #254
sinasalek CreditAttribution: sinasalek commentedMore insight on the issue,
- Upon creation of new node, the field collection item is saved twice, one record for the active language and one as Undefined (und).
- When adding a translation for another language, upon saving two more records are added. again one for und and one for active language
For the last record the delta is 1, but for the rest is 0, which does not seem correct
- The field collection field i created contains a single translatable text field.
And here is its contents, as you can see both records language is en which is incorrect, second record should be fa
So why there are two und record for field collection? and why translatable fields language is always equals the source language?
Lets see what happens if we add a non translatable field to our field collection field.
The news field table although i entered value for it is empty! but when i edit the node,
it's filled! i check the revision table and there it was. a new revision was added
Also the non translatable field did not sync between translations and remained separate, how?
Two different records where added to revision table!
The patch needs a serious review
Note that, for translatable fields, the language gets corrected after editing the translation so the incorrect language issue happens on creation
Comment #255
jmuzz CreditAttribution: jmuzz commentedYou need to choose between having a field collection with translatable fields and having the field for it in its host be translatable. It doesn't make sense to combine the two. Chances are you want the fields inside the collection to be translatable. Try making the field for it in the host entity untranslatable.
Comment #256
sinasalek CreditAttribution: sinasalek commentedWell you may have a point there but i tried that too and still encountered several issues like three records.
I suppose according to what you mentioned there should be only one for each language
Also the translations are stored inside the field table and as you can see language of them both is en, which causes the translation not to appear on view and can probably cause problem for edit too when a third translation
is added.
According to what you said, the language should be und
Also the problem with this approach is that all fields inside a field collection will become translatable which is not the way that entity translation works. for example if i have an age number field, it does not need to be translated and therefore should be available for translation. at least that's the way entity translation module works.
So when i make a field collection translatable, it means that what's inside it is translatable because field collection itself does not contain any value it's only a container for another entities.
As far as i know the are two use cases :
- field collection records are the same and their fields might be translatable
- field collection records may vary for each language and their fields are language specific and therefore non translatable
For Nodes, we have several options which cover almost all cases :
- Enabled
- Enabled, with translation
- Enabled, with field translation
For field collection i think we need only the first and the last.
So when enabling translation for a field collection we can decide whether we want each language to show different items or the same but translated.
There are more complex use cases also like mixing cross language items and per language ones, but i think that's out of the scope of this patch.
Comment #257
sinasalek CreditAttribution: sinasalek commentedAlso the reason we may need another option on field collection settings is because entity translation automatically removes the non translatable fields from the translation pages because apparently there is no point in showing them. But for field collection it causes problem because it's a container and the field inside it might be translatable and removing it makes it impossible for the fields inside it to be translated.
A alteration here can probably for entity translation not to remove field collection fields from the translation pages
Comment #258
jmuzz CreditAttribution: jmuzz commentedYou can choose which fields in your field collection are translatable if you make the field corrosponding to it in its host untranslatable. If you make its field in its host translatable then there will be a separate copy of the field collection (or group of field collections if it is a multiple entry field) for each language and in that case all of the fields in it will be translatable and the translation options you have set for the fields inside the field collection will not work and probably cause problems if some of them are translatable, so you have to choose one or the other, you can't have both the fields inside the field collection translatable and also the field corrosponding to the host in the field collection translatable.
Most likely scenario is you want to have the same data in each translation but with different text. In that case you want to make the field for it in the host untranslatable. There will just be one field collection item (or one group if it is a multiple entry field) in the host and it will have 'und' language. The fields inside the field collection will have 'und' for the untranslatable fields and separate entries for each language in the case of the translatable fields.
You will need to turn off the option to hide untranslatable fields if you want to do it using the embedded widget. Another option is to use the form pages for the individual field collection items linked from the "field collection" formatter or "links to field collections" formatter.
Comment #259
jmuzz CreditAttribution: jmuzz commentedI think I understand the previous comment better. There's been an outstanding issue with this patch where the embedded widget will put the (all languages) clue on every subfield in a field collection item if the field for it in its host isn't translatable. It should still function correctly despite the hints.
Here's a version of the patch that makes an attempt to get those hints set correctly.
Comment #260
sinasalek CreditAttribution: sinasalek commentedTx alot for the quick update i'll test test patch
If i want to the field collection items to be the same all languages but the fields inside them translatable. Do i still need this patch?
Comment #261
jmuzz CreditAttribution: jmuzz commentedYeah definitely, that's mostly what the patch is for.
If you want the field for it in its host to be translatable instead then a simpler solution might work. I think #108 was only trying to get that working.
Comment #262
sinasalek CreditAttribution: sinasalek commentedI tried you suggestion with and without the patch but it doesn't work. Even though the fields inside the host are translatable and field collection is set to non translatable, still when i save the node and its translation the values are the same and the change on all translations.
Comment #263
jmuzz CreditAttribution: jmuzz commentedThanks sinasalek.
Both ways should work before the patch is committed.
Comment #264
sinasalek CreditAttribution: sinasalek commentedYou're welcome, you can count on me to review and test the patches quickly :)
Comment #265
jmuzz CreditAttribution: jmuzz commentedI wasn't able to duplicate the behavior described, but I did make a change to stop the extra LANGUAGE_NONE field collection item from getting created.
If it's still happening, can you give details about how to duplicate it from a clean install?
Comment #266
sinasalek CreditAttribution: sinasalek commentedSure, i'll get back to you with more accurate insight
Comment #268
sinasalek CreditAttribution: sinasalek commentedHere is the first insight :
- Fresh Drupal install
- i18n + entity translation
- Enabled locale module and added two languages
- Language detection for both interface and content set to URL
- field collection dev with patch applied
- Created a content type :
- Enabled, with field translation
- Skills : field collection field is set to non translatable
- Name text field : translatable
- Years integer field : non-translatable
- Created a new content in english
- Added one items to skills
- saved and added a translation for Persian language.
- Entered translation for Skill item , name field
- Saved
Issues :
- When viewing the created node in English, the skill name field appears as translated! and the original value is overwritten after saving the translation
- In node translation page, near the label of Skill Name field it's written (all languages)!
- When viewing the translation , the skill name does not appear as if it's empty
- In database tables of field collection and years field show only one und record which is correct but for skill name tables, there is only one en record. but there should be one record for each language.
Ok now test it with translation field collection host :
- The only problem i encountered was that, i created a translation for the node, and removed the skill item added previously upon creating the node and saved. but on node translation view, the items was shown.
I edited the translation, and nothing was there! so i added an items saved it (new items appear), edited the original node , removed the skill item and saved. Now the item i added for translation appeared!
Note that database records where correct, it seems that there is a problem with field collection view
Comment #269
jmuzz CreditAttribution: jmuzz commentedYou tested the case where the field in the host is not translatable, and there are translatable fields in the field collection first, right? You need to set field collection items as one of the translatable entity types at /admin/config/regional/entity_translation before that will work.
Before testing the case where you make the field in the host translatable make sure none of the fields inside the field collection are translatable.
Comment #270
chipway CreditAttribution: chipway commentedTested this patch on dev.
Node type page with a translatable field collection field_block (title untranslatable, type untranslatable, body untranslatable).
Previous errors :
1) When we added a translation we got undefined language on field_blocks attached to the translated node.
2) Then, when we saved an edited field_block, it added a duplicate (und language) item for the updated item. And the original item was not updated but displayed in view.
After applying the patch, we can add a translation for our field collection host node, and get all field_blocks saved. During the translation, we can remove some field_block item or add new ones.
field_collection-et-1344672-265.patch works, for our use case.
Comment #271
sinasalek CreditAttribution: sinasalek commented@jmuzz, thanks for the explanation. now it works. However the behavior is still not entirely correct.
- When i remove a field collection item on any translation or even the original one, it is not removed from the rest of them and still appears. Only the translation is remove, making it show for example the translation value for the original language. When i edit the node add a new item, it does not appear for translations which makes it impossible to translate the new item via node UI.
- When the source language of the node and also the field collection item is set, it still shows (all languages) near translatable field inside field collection. however it's fine on translations when adding them for the first time but when editing, again it shows (all languages)
Comment #272
alcroito CreditAttribution: alcroito commentedI believe I have found the problem related to why (all languages) appears for all fields in the field collection widget, related to what @sinasalek mentions in comment #271, point 2.
It is indeed correct to set the '#multilingual' property on the field collection widget element, but it is also necessary to set the property on all the translate-able field widgets inside the FC widget. This is usually done automatically by the entity_translation module in the "entity_translation_field_attach_form()" hook, specifically line ~1220, where it does this check.
The problem is, the conditional fails, because count($translations->data) will return == 1, if you have for example only English and Spanish, whereas to pass the conditional it has to be at least two.
I assume it works for nodes for example, because the original "English" is also considered a translation, so the count equals 2.
If you look at the comment it says that at least one translation has to be available, so maybe this is a bug in entity_translation, and the check should actually be "count($translations->data) >= 1".
Alternatively we could copy the same code which entity translation does, and execute it in a hook_attach_form (or somewhere), specifically for field collections only.
Regarding point 1 in comment #271, I cannot reproduce this case, if I delete one FC item, it is also removed from the translations as well.
For me, applying the latest patch in #265, actually fixes both use cases: when the FC is not translateable, and the fields in it are, and second case when the FC is translateable, and the fields inside are not.
It seems like the patch got to the point where it's mostly usable.
Comment #273
alcroito CreditAttribution: alcroito commentedAttaching patch with proposed fix to reimplement entity_translation behavior, for setting the '#multilingual' property for FC widgets.
That is the only change from the # 265 patch. This should make the labels (all languages) appear only for non-translateable fields.
Alternatively, you can try and use the patch I've posted against entity_translation, here -> #2371065: Translation "Shared Fields Handling" check is not correct
Comment #274
xumepadismal CreditAttribution: xumepadismal commented#273 works well for me. Shared labels is OK now.
I have a question though. #237 changed ::getLanguage() logic to use ->getFormLanguage() instead of ->getLanguage(). I believe there IS a reason of doing that, but I'm experiencing a bug related to this change. I have non-translatable FC field with multilingual fields in it. This FC is attached to the node type with 'embedded' widget. And when I trying to add translation to the Node, that translation is OK, but for all other languages it shows 'Translation unavailable' message for FC field. However, when I click 'Edit', I can see all the values in the form for all languages.
Changing ->getFormLanguage() back to ->getLanguage() fixes this problem nicely, but I have no idea what bug(s) it can (re-)introduce.
Comment #275
alcroito CreditAttribution: alcroito commented@274
I've changed the getLanguage() to getFormLanguage() because of an issue how values were saved when adding a translation, and on a subsequent edit, didn't show the stored values. Like you I'm not certain if that was a cause of the error, or a symptom of something else.
We can try to re-roll the latest patch without the getFormLanguage() call, and see if we have any regressions, when people review the patch.
But personally, I did not encounter your problem.
Did you make sure that after applying the patch, you enabled entity translation FC translation handler, and that the handler was in the proper folder after applying the patch, and not in drupal root?
Comment #276
xumepadismal CreditAttribution: xumepadismal commented@Placinta, yes I applied patch properly in the FC folder and the handler is enabled.
However, I will install clean Drupal with ET & FC and come back with all steps to reproduce the bug.
Comment #277
xumepadismal CreditAttribution: xumepadismal commentedSo, I figured out that this problem appear only with disabled language fallback in ET settings. Here are the steps:
And here is the cause/guess: \EntityTranslationDefaultHandler::saveTranslations deletes ALL records for the current entity from 'entity_translation' DB table and then inserts all available translations. So \EntityTranslationFieldCollectionItemHandler::getLanguage is called for each translation of the node. Hence we can't rely on getFormLanguage() here because it returns the same language for all translations which is not correct.
Meanwhile, I'm not experiencing any degradation on using ->getLanguage() so far. So it would be great to modify it and let people to review, as you mentioned above :)
Comment #278
alcroito CreditAttribution: alcroito commentedYes, I can reproduce your issue, and indeed changing getFormLanguage to getLanguage fixes it.
But sadly it introduces the regressions I've encountered before, specifically:
If the FC field is not translatable, and the fields are inside are translatable / non-translatable, everything works fine.
If the FC field is set to translatable then:
- non-translatable fields inside the FC work fine
- translatable fields inside the FC do not work properly.
What doesn't work for the last case:
- When adding a translation for the first time, any values you enter in the translatable fields in the FC, are lost upon save. Aka after adding the translation, and editing it, the value will not show up in the widgets. If you enter the values a second time, and save the translation, it will save the values. But,
- Some funky stuff happens in the database. The actual values on the first save are not lost, but are saved with an improper languages set ( the original language). When you save the translation a second time, the values are saved with the proper translation language.
- When you delete the node / node translation, the created FC entities for translations are not removed, neither from the fields tables, nor from the field_collection_item table.
So I'm not sure what's the best course of action here. If we change getFormLanguage() to getLanguage(), we lose the ability to use the second use-case of FC translation:
FC field is translatable, as well as the fields inside.
Comment #279
sinasalek CreditAttribution: sinasalek commentedCan't we decide which one to use depending on field collection language settings ?
for example if the field collection is translatable using getFormLanguage
Comment #280
alcroito CreditAttribution: alcroito commentedWe can try doing that, but the issue with language fallback that @xumepadismal mentioned, will probably still be present.
Comment #281
xumepadismal CreditAttribution: xumepadismal commentedIt rather strange but it seems that I can see all problems discribed in #278 regardless of using ->getLanguage() or ->getFormLanguage() :/
@Placinta, could you check this please?
Comment #282
jagilpe CreditAttribution: jagilpe commentedHi! I'm working in a project where we are using the field_collection module in a multilanguage site translated using Entity Translation. We had to develop a patch for field_collection in order to support the entity translation in the use cases that we have in our project.
We have tested the patch uploaded in #273, to see if it works in all our use cases but we have found two where it doesn't work as we expected. Specifically:
We need to support translatable fields in field collections because we may need to add a field that is already used in another entity type, where it needs to have entity translation enabled. This is a field-wide configuration and therefore we can not disable it only for the field collection case.
We are working in a module that tries to ease the translation workflow in an multilanguage environment with complex content structures, and we need to support the creation of translation, not only with the normal translation edit form, but also programmatically.
We have also written tests for different use case and scenarios.
Attached is this patch against the latest dev version.
Comment #283
seanr@jagilpe - your reroll is missing includes/translation.handler.field_collection_item.inc and the reference to it in field_collection.info. What happened there?
Comment #284
jagilpe CreditAttribution: jagilpe commentedThe patch was written from the latest dev version of the module, and before the patch of #265 was uploaded, and therefore is not this file in the patch. We used a language callback instead of an EntityTranslationHandler to return the language of the entity.
I have modified our code starting from #273 to include the EntityTranslationHandler.
Now all our test pass, with the exception of one of them. When a new field_collection item is added programmatically the translatable field is not saved.
Comment #285
seanrI'm attempting to test that patch, but after configuring everything I now get Maximum function nesting level reached no matter how high I set the option (even 800 gets hit). Are there any configurations that could cause this or would we be looking at a code issue? It's getting caught in a loop with these three functions called over and over:
Comment #286
loopduplicateI had similar issues to #285. I couldn't get the patch in 284 to work. 273 seems to be ok for the project I'm working on but I still need to test more to be sure.
Comment #287
seanrThis is actually happening on all nodes with field collections, even with types not set to be translatable.
Comment #288
seanrSomething is still very wrong here with the patch from 273. Translating to the first language after the source language works, but then when you try to add a third language, all translatable fields end up blank. Furthermore, when you go to the direct URL for translating that field collection item (i.e. http://example.com/en/field-collection/field-poll-options-collection/264...) you see the second language showing as the source language and the original shows as untranslated. When I go to the entity_translation table in the database, there is only one record for the item, with the language listed as french (which was actually the second language - it was originally set to english). If I actually do save the third translation, I then end up with two records, one set to the third language with the second as the source, but then the previous language is actually set to what it originally was (WTF?!?!?). Here's the status of the entity_translation table after these shenanigans:
Comment #289
seanrFurthermore, I'm noticing that new nodes created with field collections don't appear to be saving their field collection items at all right now.
Comment #290
seanrOK, second problem is specific to that site's codebase. Doesn't do that on a clean install, but the first bug mentioned in #288 does happen. Interestingly, if you go back and save the source language after adding a translation, the source language record gets saved correctly and then adding the third language will work. So we're not saving the record correctly when creating a new field collection or setting one as translated for the first time (still only in source language, but no longer und).
Comment #291
seanr@jagilpe - what's going on here in your patch from #284?
Specifically this seems very wrong:
I'm pretty sure that's the cause of the infinite loop in your patch. Also, why the hardcoded 'de'?
Comment #292
seanrHere's an updated patch which fixes the issue for me, but I'm not sure this is the right way to handle this. Would very much like some thoughts on this. I've attached my patch as well as an interdiff between this and 284 to facilitate review.
Comment #293
seanrIncidentally, the important part of that is the last hunk in the interdiff (the rest was getting 273 into a working state). Basically, updateTranslations() calls setOriginalLanguage() which for reasons I simply cannot understand runs $translations->data[$langcode] = $translations->data[$translations->original]. What's the purpose of replacing the current language data with the original language data? It works with nodes which have their own language property (which always seems to be the source language), but it breaks field collections pretty badly.
Comment #294
fxfx CreditAttribution: fxfx commentedHi Sean did u get ET work with ur last patch #292 ?
My setup is a CTYPE with a Field, (FIELD Collection) Translation Enabled and than inside field collection enabled translation for a DESCRIPTION FIELD
i started from the latest dev 04 Nov. i applied patch #292 directly i tried to enable also FC as tralatable entity but in all cases i get the handler ERROR
Can you tell me how should i proceed to get the FC work with ET?
Comment #295
opdorp CreditAttribution: opdorp commentedHi, i had the problem with ET that the host entity had 2 languages with the same Field Collection item.
I started with the patch from #265 and added these 2 lines.
I gave the right langcode to the set the host entity so it wouldn't make an unused LANGUAGE_NONE field collection entity.
Comment #299
fxfx CreditAttribution: fxfx commentedok So i need to apply your #295 from a clean instal of the dev version?
Comment #300
seanrfxfx, you should apply the .patch file (not the interdiff) from 292 to a clean copy of the dev version. The patch from 295 I believe would apply on top of that.
opdorp, please reroll that as a complete patch including the changes from the previous patch so it can be tested more easily.
Comment #301
sarath.rajan CreditAttribution: sarath.rajan commentedCan anybody help me to translate a Field Collection field using Entity translation?
Comment #302
seanrUpdating shown files - #295 was only a partial patch (I think a patch against a patch?) so hiding it from the main list. Also hiding some older patches that have been superseded.
Comment #303
seanrAlso, moving back to Need Review (since the needs work was generated by the aforementioned erroneous patch).
Comment #304
james.williams CreditAttribution: james.williams commentedThe attached patch is the one from comment 292, plus the change from comment 295's interdiff (if I've understood it correctly). This has not been tested (sorry!), but has been put together for the convenience of those looking to move this issue forward.
Comment #305
seanrThat patch seems to be missing includes/translation.handler.field_collection_item.inc.
Comment #306
maxplus CreditAttribution: maxplus commentedHi,
patch from #304 applied OK on the current dev version for me.
I uploaded to my live site and it works
Thanks!
Comment #307
colanUpdating status based on #305.
Comment #308
emasclans CreditAttribution: emasclans commentedI currently have:
Field collection 7.x-1.0-beta6+21-dev
Entity Translation 7.x-1.0-beta3+21-dev
Internationalization 7.x-1.11
I apply the patch and I get this error when creating new Field collection field...
EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7766 of ...includes\common.inc).
Any idea?
Eugeni
Comment #309
jwilson3Added back translation.handler.field_collection_item.inc
Comment #310
alcroito CreditAttribution: alcroito commentedTested latest patch in #309 using Nodes and Fieldable panel panes. Used latest DEV version of FPP and Entity Translation and Field Collection with this patch.
Node with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.
FPP with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.
Node with 1 translatable unlimited-value FC (and with translatable fields inside it) partially works.
When deleting the node, some stale values for FC fields remain in the DB.
FPP with 1 translatable FC (and with translatable fields inside it) partially works.
On first save / insert field collection values are not saved. On second save they are saved.
When you add a translation from English -> Spanish, the old FC values are not copied over, so you get an empty widget.
But once you add the values again, it seems to work properly.
Also sometimes a LANGUAGE_NONE entry for the FC fields is created.
Bottom line, untranslatable FC (with translatable fields inside them) seem to be usable.
Translatable FCs (with translatable fields inside them) still needs some work.
Comment #311
seanrIt would seem to me the FPP should be tested after we ensure the base functionality with nodes is working correctly - it might even resolve itself at that point, or prove to be an issue with FPP.
Also, can someone explain to me the specific use case in which you'd want the FC field on the host entity to be translatable as well as the fields within the FC? Wouldn't that be redundant, and maybe even conflicting? How would you ever see or edit the translated values of the FC's fields if the host FC field was itself translated? I'm wondering if the patch should actually prevent you from enabling both at the same time - force it to be an either-or thing.
Comment #312
sinasalek CreditAttribution: sinasalek commented@seanr I also don't think that having both Host and fields translatable has any use case. Preventing the user from setting it saves us lots of incorrect bug reports
Comment #313
alcroito CreditAttribution: alcroito commented@seanr I can give you an example when that happens.
Say you have Node type Slideshow, and an unlimited value FC called field_slide_fc, sou can create a slideshow, with multiple FCs serving as slides.
Now, in case if the FC is untranslatable, but the fields inside it are translatable, that means that all language versions will have the same number of slides, and the only thing you can control is changing the contents of the slide, so you're stuck to 3 slides on all languages of the node.
If the FC is translatable, that means you get separate FC ids for each field collection, which means Language A can have 4 slides, whereas language B has 7 slides.
Now how can it happen that there are also translatable fields inside the translatable FC? Simple, if you re-use fields in multiple content types, like the Title field, you want to enable translation for the title field. And you add the title field to the slide FC so you each slide has a title, and bam -> translatable field in translatable FC.
Of course someone will come along and say, just create another title field that is untranslatable, but that defeats the purpose of re-using fields, which IMO is a good practice.
Regarding to "how can you see / edit the translatable field inside the FC", currently in the DB both fields are saved and loaded with the same lang code, so that's how you see and edit. E.G:
ID1 FC langcode EN
- title_field langcode EN
ID 2 FC langcode ES
- title_field langcode ES.
The widget code loads the same language codes for both the FC and fields inside it.
Comment #314
jmuzz CreditAttribution: jmuzz commentedUntested reroll for latest dev.
@placinta makes a good point it should be possible to reuse an existing translatable field in a field collection referred to in a translatable field since it is possible to reuse translatable fields in content types that are not translatable.
Comment #315
jmuzz CreditAttribution: jmuzz commented#314 was missing required changes to field_collection.entity.inc .
Comment #316
jmuzz CreditAttribution: jmuzz commentedWhat exactly is the problem with translatable field collection items with translatable fields in them? I tried the example described but it seemed to work ok and after deleting the node no values from it were left in the field_data tables for the field collection item field or the fields in it.
Comment #317
jmuzz CreditAttribution: jmuzz commentedCreated an untranslatable content type with a field collection nested in a field collection. The deeper field collection contains a text field. No fields are translatable but the patch is applied and entity translation is activated for field collections. When creating a new node of this content type it mostly works but immediately after saving this notice appears:
Comment #318
jmuzz CreditAttribution: jmuzz commentedThat notice should be fixed.
Comment #319
alcroito CreditAttribution: alcroito commentedHaven't tested the patch yet, but one thing to keep in mind is that the added tests in the patch are not executed by the test bot. Probably because test_dependencies[] = entity_translation wasn't set?
Also the tests to do not enable translation of field collections at 'admin/config/regional/entity_translation', which is required to make translation work properly.
Comment #320
jmuzz CreditAttribution: jmuzz commentedThanks @Placinta.
Can you take a look at #316 because I really do not understand what the issue was.
Comment #321
jwilson3jmuzz *please* attach interdiffs, its quite hard to see whats changing between versions.
Comment #322
jwilson3Comment #323
jwilson3NW per #319.
Comment #324
jmuzz CreditAttribution: jmuzz commentedI still don't get in what way translatable fields inside translatable field collections aren't working correctly.
Comment #325
alcroito CreditAttribution: alcroito commentedHaven't been able to test the latest patch yet, maybe over the weekend.
But I wanted to point out, that the entity translation tests still aren't running for some reason.
Comment #326
jmuzz CreditAttribution: jmuzz commentedAnother problem with nested field collections. I have an unlimited cardinality field collection with an unlimited cardinality field collection inside it and a text field inside that. No fields are translatable and the content type is not translatable, but entity translation is active for field collections. I can "Add another item" on one level of the embedded form (child or parent field collection) as many times as I want, but then when I try to add another item on the other level it seems to have an infinite recursion causing a function nesting level error. Here is a part of the trace:
It keeps going like that.
Comment #327
jmuzz CreditAttribution: jmuzz commentedIt may have something to do with translation handler IDs being reused. They should probably be unique, but since they are generated by separate AJAX requests the counter gets reset. I replaced "self::$newId++" in translation.handler_factory.inc with "rand()" as a quick test and the error no longer occurs.
Comment #328
wla_g CreditAttribution: wla_g commentedThere is an error in the field_collection.info file. The translation handler is not in the includes subdirectory (that doesn't exist) and from that I've got the error "PHP Fatal error: Class 'EntityTranslationFieldCollectionItemHandler' not found". After fixing the .info file the error vanished.
Comment #329
jmuzz CreditAttribution: jmuzz commented@wla_g A couple of times an incomplete version of the patch that didn't include these files got uploaded but the most recent version of the patch should create the directory and the file. It is the last thing in the patch file if you want to see it. You can add the file manually from that if applying the patch doesn't work.
Comment #330
jmuzz CreditAttribution: jmuzz commentedI'm no longer able to duplicate the infinite loop I was seeing before.
Comment #331
jmuzz CreditAttribution: jmuzz commentedOh yeah I actually fixed the infinite loop. I am not sure if this is the best way, as I don't understand why reusing these IDs would cause the loop in the first place, but it seems to work.
Comment #332
Soul88Hello, Joel. I've tried your patch, but unfortunately the content of the field_collections disappear from the node edit form after I apply your patch and run update.php. (You can still see the content on the node view page)
In order to try to reproduce it you would need to download and enable the following modules:
drush en admin_menu devel module_filter -y
drush en smartling -y
drush en smartling_reports -y
drush en smartling_demo_content -y
And I attach my test DB
P.S. You can ping me on skype if you need mode info - skype: soul-dreams
Scencerely yours,
Kostya
Comment #333
ciss CreditAttribution: ciss commented@jmuzz: Since misconfiguration can be a source for false error reports, do you think you could create a feature (or a db dump) of your testing installation (configuration, fields, node types etc) and provide a list of the module versions/revisions you're using?
That would allow others to reproduce your results and determine errors that get introduced by other modules or misconfiguration.
(On a side note: I can also imagine that some people have thoroughly screwed up their installations by now by applying some of the intermediate patches in production.)
Comment #334
jmuzz CreditAttribution: jmuzz commentedThanks @Soul88, fixed a bug in the update that was preventing it from doing anything.
@ciss I wipe my test installation regularly, and as far as I know I'm using the latest version of everything. In any case that is what the target should be, not necessarally the versions that I happen to have right now.
I agree about the misconfiguration problems, I will try to add some information to the README to address them.
Comment #335
jmuzz CreditAttribution: jmuzz commentedREADME updated.
Comment #336
Soul88Unfortunately I've got error on the same DB:
:(
Comment #337
daro.pl CreditAttribution: daro.pl commentedI've got following notices
Comment #338
Soul88Comment #339
jmuzz CreditAttribution: jmuzz commentedCan anybody provide steps to reproduce these errors from a clean install?
Comment #341
Georgique CreditAttribution: Georgique commentedSorry, requested retest of an old patch just by occasion.
Comment #343
Georgique CreditAttribution: Georgique commentedWhat this line in EntityTranslationFieldCollectionItemHandler::getLanguage() means?
$handler = $this->factory->getHandler($host_entity_type, $host_entity);
Seems that factory is an undefined property...
Comment #344
jmuzz CreditAttribution: jmuzz commentedYou will have to look at the relevant classes in the entity translation module to understand that line.
How did you get it to give you an undefined property error?
Can anybody provide the steps to reproduce any of these reported error messages from a clean install?
Comment #345
Georgique CreditAttribution: Georgique commentedI'm not reporting any errors yet. :)
That was just my code where I create field collections programmatically, it worked with unpatched FC module, and became buggy with patched one. Now seems I fixed it, no errors. Update also was fine.
Comment #346
Georgique CreditAttribution: Georgique commentedI've rechecked and can now say following:
When this line is executed I always have an error about undefined property. I have a node which is translatable. When I try to create field collection for this node which is not translatable, that is when the line is executed.
I'm pretty sure there is a bug here.
Comment #347
jmuzz CreditAttribution: jmuzz commented@Georgique Are you using the latest version of entity translation? EntityTranslationDefaultHandler should have a factory property.
Comment #348
Georgique CreditAttribution: Georgique commented@jmuzz Just got ET beta4 update, now I see factory property.
We should add version requirement to dependencies in FC module.
Will test the patch further.
Comment #349
jmuzz CreditAttribution: jmuzz commentedI'm going to put this back to needs review. Please don't change it to needs work unless steps can be provided to reproduce any problem behavior.
Seems like it is mostly working now. It might make sense to commit it and save any remaining issues for future tickets. Thoughts?
Comment #350
ciss CreditAttribution: ciss commented@jmuzz: I wholeheartedly agree. This issue has become a mixed monster that's hardly maintainable anymore.
Someone who's deeply familiar with the problem should probably take a second look (e.g. Placinta). Beyond that, I'd vote for commit and close.
Comment #351
Georgique CreditAttribution: Georgique commentedI can confirm it works for me. So I'm also +1 to commit.
Comment #352
sinasalek CreditAttribution: sinasalek commentedSince without this patch, field collection is unusable for entity translation, as long as it does not cause problem in normal usage which it doesn't it seems, i think it would be a good idea to do a final review and commit it. if there was any reproducible problem, they can be taken care of separately.
I'm always against big patches, keeping up with the dev wastes lots of energy
Comment #353
jmuzz CreditAttribution: jmuzz commentedSoul88 actually did provide the test data (#332) used to generate the error (#336) he reported.
Comment #354
omarlopesinoI applied the patch and i can translate a field collection, but i found several bugs.
I was using entity_translation in the development version.
1) I can't translate the fields of the field collection separately. In addition, if i have an entity with a field collection, and only i enable translation for one field of the field collection, i can't add translations.
2) When i'm adding the translation, if i have to change the image, i can't. When I click the remove button it doesn't happen anything. I have to save the translation and edit the translation again.
Comment #355
Georgique CreditAttribution: Georgique commentedMy five cents:
1. Removed blank string.
2. Removed line where we retrieve translation handler which will never be used.
3. ET setting "Show shared labels" was not respected. Fixed this.
Comment #356
alcroito CreditAttribution: alcroito commentedTested latest patch in #355 using Nodes and Fieldable panel panes. Used latest DEV version of FPP and Entity Translation and Field Collection with this patch.
Node with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.
FPP with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.
Node with 1 translatable unlimited-value FC (and with translatable fields inside it) partially works.
The previous issue "When deleting the node, some stale values for FC fields remain in the DB." is still present, here is how to reproduce.
0) Have a node CT with 1 translatable unlimited-value FC (and with translatable fields inside it)
1) Add a node in English language with 1 field collection item.
2) Click translate to Spanish, and save the translation node.
3) Click edit for the translation node, and then click Delete translation.
4) Click edit for the original node, then click delete node.
Now check the database, and you should have stale values in the field_data/revision of fields inside FC, as well as in field_collection_item/revision tables.
Note that if you don't delete the translation first, but delete the original node (which deletes all translations), the issue does not happen.
There is another issue which I stumbled upon.
0) Have a node CT with 1 translatable unlimited-value FC (and with translatable fields inside it)
1) Add a node in English language with 4 field collection items.
2) Then click translate to Spanish.
3) Click "Add another item" once, the 4 previous FC items will be removed, and only 2 will remain, with the original data in them.
4) Click "Add another item" one more time, and a third item will appear, which is empty, and does not contain the original data.
I suppose it is somehow related to the fact that the FC item count is considered to be equal to 1 on the translation add page.
FPP with 1 translatable FC (and with translatable fields inside it) partially works.
On first save / insert field collection values are not saved with a proper language code, which means on view you see the values, but when editing, the widget is empty. On second save they are saved properly.
Also a LANGUAGE_NONE entry for the FC fields is created, which is linked to the problem described above.
You cannot delete an FPP translation, only the original FPP entity, together with all other translations.
One more usecase that I tested, I will use indentation to show fields inside other fields:
So every field is translatable. Now to the use-case.
1) Add a Node in English with some text added in fields, and at least two field collection items (both inner, and outer), save it.
2) Click translate to Spanish, just click Save, and I get a fatal error.
Note that with the same structure, and making the inner and outer FC untranslatable (but the fields inside translatable), then everything works properly, and no errors occur.
Sorry for the wall of text.
Comment #357
alcroito CreditAttribution: alcroito commentedOn an unrelated node, I'm not against committing the patch as-is because it does seem to solve the simple use case when the FC is untranslatable, and the fields inside are.
And then close this gigantic issue, and open new issues for the other use-cases.
Although I am afraid that once the issue is closed, we will lose traction and interest in fixing the other smaller issues.
Comment #358
Soul88It seems also that in the current state of a patch - we are about to break "by nodes" translation. Cause what I can see on my install is the following:
We have a node with language = en. All its fields have language = "und" including FC field. But if this FC has one more FC among its fields - this field will have language = "en" instead of "und".
Comment #359
jmuzz CreditAttribution: jmuzz commentedThere are problems applying the update to nested field collections. Soul88 provided some good data to test this with in #332. I haven't figured out exactly what is going on yet but I can say it is in the area of copyTranslations, field_collection_field_update, and deleteRevision. Here is an interdiff that I -think- is closer to working, though the update still ends in an error and data is lost from the field_collection_item and some of the field collection tables when it is run.
Comment #360
joseph.olstadWe've been successfully using patch 187 for quite some time on field_collection revision ae778f2 from 2014-04-16. Is there anyone else successfully using a newer patch on a more recent build of field_collection? If so, please commit the latest working patch so that any remaining items can be dealt with in a new issue.
Comment #361
jmuzz CreditAttribution: jmuzz commentedIt looks like the update can destroy data when applied to nested field collections so I don't think it should be committed yet.
Comment #362
bartvig CreditAttribution: bartvig commentedI had problems installing patch 284 on the latest dev version, so I applied the changes to the latest dev version and that patch works for me.
Comment #363
bartvig CreditAttribution: bartvig commentedWrong file name in previous post fixed.
Comment #364
joseph.olstadMarking to needs review, hoping that the testbot catches #363
Comment #365
joseph.olstadTestbot doesn't seem to be awake, renamed patch from 363 to adhere to naming convention.
**EDIT** ok, testbot woke up and tests all-green
Comment #366
asamant6 CreditAttribution: asamant6 commentedThe patches for filed_collection module are not working properly. If user wants to translate fields, the content of translated fields are replicated into the main content. We have working on this module to develop a patch from TCS, JNJ team to make this module supported for multilingual system.
Comment #367
jmuzz CreditAttribution: jmuzz commentedLatest version of patch is #355, which still has issues with the upgrade mentioned in #359.
I don't understand why a reroll of #284 was put up for review. Several issues with #284 have already been found and fixed. If you need to run tests you can set up the test module locally.
Comment #368
sylus CreditAttribution: sylus commentedPlacinta has said he wouldn't be against committed the patch in #355 and then tackling the smaller issues separately. I am personally having a hard time following this issue. If the only major blocker at this point is an issue with nested field collections can that not be pushed into a separate issue and tackled separately?
I fear this issue is getting very much out of hand and will not be closed otherwise as we will never reach a 100% acceptable state. In my experience it is often easier tackling a smaller subset of problems in clear defined issues.
Comment #369
jmuzz CreditAttribution: jmuzz commentedThe issue with nested field collections is not really a smaller issue. People with nested field collections may see their data be deleted when they run the update in this patch.
Comment #370
ciss CreditAttribution: ciss commentedI'd like to make a bold proposal: In my opinion the size and complexity of this patch goes beyond what is managable in a patch based workflow, when there are no tools around to review and comment on patches.
Github on the other hand allows each line of a commit to be commented. I therefore propose this:
This should make it a lot easier to provide background information on certain key parts / design decisions of a patch.
Comment #373
ciss CreditAttribution: ciss commentedI went ahead and created branches and pull requests for the patches in #331, #334, #335, #355 and #359. I left out everything after since @jmuzz already stated that these were obsolete.
Pull requests can be found, reviewed and commented on at github.com/cisso/field_collection. The commit each patch was based on was determined with the help of this script.
I'm hoping that his will help everyone who wants to get involved to get more familiar with the issue and the underlying code.
Comment #374
ciss CreditAttribution: ciss commentedReviewing #359 against 7.x-1.x (pull request):
field_collection.entity.inc
FieldCollectionItemEntity::setHostEntity, line 205
This is the only place left where ->langcode doesn't get sanitized. ->setHostEntity() gets called in several places – can we be sure that langcode will already be clean?
FieldCollectionItemEntity::langcode(), line 350
if (empty($this->langcode) || ($this->langcode != LANGUAGE_NONE && (!module_exists('entity_translation') || !entity_translation_enabled('field_collection_item')))) {
Shouldn't be necessary, as field_collection_entity_language() already defaults to LANGUAGE_NONE. Imo the overzealous sanitization could even make other problems go by unnoticed.
FieldCollectionItemEntity::copyTranslations(), line 460
Shouldn't there be a call to field_info_field() with a check on $field['translatable']? Edit: Looks this patch marks all fields of a translatable FC as translatable (in field_collection_field_attach_form()).
FieldCollectionItemEntity::copyTranslations(), line 467
Why is this necessary?
includes/translation.handler.field_collection_item.inc
EntityTranslationFieldCollectionItemHandler::getLanguage(), line 39
If I'm not mistaken then $this->entity->langcode() will never return an empty value (already defaulting to LANGUAGE_NONE).
field_collection.module
field_collection_item_delete(), line 361
if (!empty($fci)) {
Unrelated bugfix? If so, it should probably be committed right away.
field_collection_field_update(), line 516
$delta is not used. Should it still be kept?
field_collection_field_update(), line 541
Is this block only required for entity_translation? Otherwise it should probably be commited right away.
field_collection_field_update(), line 560
if ($field['translatable'] && module_exists('entity_translation') && entity_translation_enabled($entity_type)) {
"$entity_type" should be "$host_entity_type" here.
field_collection_field_delete(), line 591
Why is checking field_info_field($field['field_name'] no longer required?
field_collection_field_formatter_settings_form(), line 733
Another change that appears to be unrelated to entity_translation.
field_collection_field_formatter_settings_form(), line 744
Looks like this line actually belongs to $elements['translate'].
field_collection_field_widget_form(), line 1066
This should probably use uniqid() instead of rand().
field_collection_field_attach_form(), line 1151
I'm not sure about this one. Wouldn't the sub fields actually have to be shared across languages?
field_collection_item_set_host_entity(), line 1598
Again, defaulting should already be covered by field_collection_entity_language().
field_collection_item_is_translatable(), line 1663
return (bool) module_invoke('entity_translation', 'enabled', 'field_collection_item');
entity_translation_enabled() is not a hook implementation. This is abusing module_invoke(). function_exists() or module_exists() should be used instead.
What's left
I haven't yet reviewed field_collection.install, field_collection.pages.inc, field_collection.test and the functions field_collection_entity_translation_delete() and field_collection_entity_translation_insert().
Also, this was merely a code review. I didn't perform any functional tests.
Additional thoughts
I noticed that there are three places where field collection items get cloned. Especially with properties referencing other objects this may have unexpected results. I'd suggest to implement FieldCollectionItemEntity::__clone() to make the process more transparent (and reduce duplicate code).
Comment #375
jmuzz CreditAttribution: jmuzz commented"there are no tools around to review and comment on patches." ?
You have got to check this out:
https://dreditor.org/
It integrates directly with the interface of drupal.org.
Comment #376
ciss CreditAttribution: ciss commentedOK, done for the moment (my brain needs a break). I've updated my previous comment.
@jmuzz: True, although I like the possibilities Github offers, like pulling in more context, direct responses and comparing different patch branches. Also, a lone interdiff like in #359 can make things even more difficult, especially with a patch of this size.
Comment #377
ciss CreditAttribution: ciss commented@jmuzz: Did you get a chance to review my review? Were you able to take away anything useful from it?
Comment #378
jmuzz CreditAttribution: jmuzz commentedIt's a nice review, but unless I'm missing something it doesn't address the problem with the update deleting data. That's the last known thing that's keeping this from being committed and any remaining changes moved forward to other issues.
Comment #379
MXTI would try patch in #355 (because of #367) but it doesn't apply on latest dev of field_collection 7.x-1.0-beta8+11-dev (2015-Mar-26):
Do I'm testing the correct patch and FC version?
Thank you for answering me
Comment #380
ciss CreditAttribution: ciss commented@MXT: #355 + #359 is the latest and needs to be rerolled against HEAD. You can find branches with the patches applied and an overview of where they diverged from 7.x-1.x in this github repo: Field collection patches
Comment #381
saniyat CreditAttribution: saniyat commentedI am getting this warning message when translating
Notice: Undefined index: field in field_widget_field() (line 582 of /var/www/computer-generated-solution-new/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 607 of /var/www/computer-generated-solution-new/modules/field/field.form.inc).
using patch of #335. Any idea to solve ?
Comment #382
hswong3i CreditAttribution: hswong3i commentedRe-roll with latest dev based on #365
Comment #383
ciss CreditAttribution: ciss commented@hswong3i: Unfortunately you've rerolled the reroll of an old patch. #355 + #359 are the current patches.
This issue already has gotten quite messy, so please be sure to read at least the most recent comments after the patch you're rerolling. #365, #363 and #362 are rerolls of an old patch in #284, as stated in at least two comments after.
Comment #384
MXTI've tested the following branch:
https://github.com/cisso/field_collection/tree/patch/1344672-359
I've found this issue:
field collections are lost or re-attached to the wrong language of the original host when you add a translation or edit an existing node.
Steps to reproduce:
Thank you very much for resolving this
Comment #385
hswong3i CreditAttribution: hswong3i commentedRe-roll with latest dev based on #355 + #359
Comment #386
jmuzz CreditAttribution: jmuzz commentedThanks for the reroll!
The issues with data deletion still haven't been addressed so I'm setting the status back.
Comment #387
adriaav CreditAttribution: adriaav commentedSame issue as #384, have patched #385 and still not working. Any help would be appreciated! Thank you!
Comment #388
adriaav CreditAttribution: adriaav commentedSeems like I could go on enabling translation for fieldset collection and disabling translation for its sub-fields. I have no need for translating subfield labels, just it's content, so this works for me.
I've just came across another issue,.. Have a multivalue fieldset collection that has a one value text subfield and a one value image subfield. While creating content everything goes as expected but when translating it I get an AJAX error, this happens when the multivalue fieldset collection has more than 1 image field value. Structure looks like described next:
ingredients (unlimited values field collection fieldset)
- ingredients text (first value, one value limit)
- ingredients image (first value, one value limit)
- ingredients text (second value, one value limit)
- ingredients image (second value, one value limit)
Second value for ingredients image doesn't show and if trying to remove/save AJAX error appears.
Have looked for this issue but didn't find anything, if it's duplicated/... please tell me.
Thank you!
Comment #389
LiamPower CreditAttribution: LiamPower commented#385 worked for me with keeping the content in the node, but it seems to always be being saved as 'en' even when the node is German/French/Italian
Comment #390
JOINSO CreditAttribution: JOINSO commentedHi, LiamPower!
I can confirm your test.
In my case, fields of the field collection are always stored as "en", without taking care of the node language.
In details, my field collection is untranslatable, but all the files inside are translatable.
When i view the node it show correct, if I see under "en", but not in another languages.
I think that the problem is inside field_collection_field_update and the choice of the correct language, but I don't make a deep code study...
Comment #391
krisgraham CreditAttribution: krisgraham commentedFixed a small typo in hswong3i's patch #385 (line 563 of field_collection.module was referring to a non-existent variable, $entity_type instead of $host_entity_type).
I haven't yet done extensive testing, but this seems to be working for me so far.
Using:
Drupal 7.36
Entity API 7.x-1.6
Entity Translation 7.x-1.0-beta4
New patch attached.
Comment #392
JOINSO CreditAttribution: JOINSO commentedHi!
I tested the last patch (#391) and it doesn't work.
Translations of Fields in field collection still saved in "en".
Comment #394
JOINSO CreditAttribution: JOINSO commentedHi!
I do some testing with patch #391.
The initial conditions are:
Node with a field collection untranslatable.
The fields in the field collection are translatable.
A node is created in English.
The fields in the collection are stored in English.
When we make the translation in another language (Spanish), fields are stored in English.
Doing some debug, I find this:
field_collection_field_insert and field_collection_field_update are called.
The first function, get "es" in field_collection_entity_language call, but in the second one, field_collection_field_update, get this values:
langcode(param): und
field_collection_entity_language: en
And then langcode becomes "und", and setHostEntity is called wiht langcode "und".
Perhaps this info can helps someone to find the issue.
Comment #395
JOINSO CreditAttribution: JOINSO commentedHi!
Until we have a solution for fields stored in English (language source of original node) rather thant the translation language, here is a quick solution:
1) If you edit the node, there is no problem and you will see the values but we now that is going to be stored in language source of original node.
2) In node view, field collections items are going to be hidden where you are viewing in the translation language.
Then someone can do this to see the data:
Create a module, and implement this function (can be improved, I know....):
function YOUR_MODULE_field_collection_item_view($field_collection_item, $view_mode, $langcode)
{
if ($field_collection_item->field_name == "YOUR_FIELD_COLLECTION_NAME")
{
if($langcode!='en') // EN IS YOUR SOURCE LANGUAGE. THIS CAN BE IMPROVED CHECKING LANGUAGE INSIDE FIELDS ....
{
$field_collection_item->content['ANY_FIELD_INSIDE_COLLECTION] = array('#markup' => $field_collection_item->ANY_FIELD_INSIDE_COLLECTION['en'][0]['filename']); // IN THIS CASE WE ARE RENDERING A FILE
}
}
Comment #396
joseph.olstad@JOINSO , it sounds like your configuration may be the problem in your case. Are you using the entity_translation module? Is it enabled? What are your content type translation settings? Are you doing node translation or field translation? Far as I know this patch is for field translation for nodes using the entity_translation settings rather than node translation. Please confirm.
Comment #397
JOINSO CreditAttribution: JOINSO commentedHi, joseph.olstad!
This is my config:
A content type with translation enabled.
One the fields is a field collection with Field translation disabled, but with every field inside are translatable.
And Entity Translation is enabled.
However, I think that the fields inside field collections must be saved under the language of their instance, no?
Regards,
JOINSO
Comment #398
seanr@JOINSO - do you have at least one other field on the node type with translation enabled? Node should be enabled with field translation, there should be one translatable field on the node (but not the FC field) and then fields with translation enabled within the FC.
Comment #399
JOINSO CreditAttribution: JOINSO commentedTitle and body.
FC with translation disabled, but fields inside have translation enabled.
Comment #400
jkuma CreditAttribution: jkuma commentedHello there,
The last patch 391 is working like a charm for my project. Thank you guys for your hard work.
Comment #401
jkuma CreditAttribution: jkuma as a volunteer commentedHello,
I've just updated the patch to avoid Drupal installation to break. Indeed, the module_load_include at the top of the install file breaks the module dependencies check during a new website installation. That include is only needed by the last hook update (field_collection_update_7007), that's why I've moved it inside that function.
Comment #402
jkuma CreditAttribution: jkuma as a volunteer commentedThe previous patch introduces a bug when using drush make command. This new patch fixes this up.
Comment #403
MXT@goldorak: what's about your field collection configuration?
Is like described here:
(Like mine described here: https://www.drupal.org/node/1344672?page=1#comment-9815261)
Or like the following:
This is an essential piece of information to see if this patch is working at all.
Comment #404
JulianVJ CreditAttribution: JulianVJ commentedHi JOINSO,
I have the same problem.
I've noticed that this only ocurr when I have 'Enable language fallback' unchecked, if it's checked it works OK.
I don't know if is related with this but reviewing database information I have seen that when I make a translation a new line to 'entity_translation' table is not added, it overwrites the initial line so entity translation don't find source language correctly.
@MXT, making the field collection field in the host translatable is not an option, at least in my case, because a memory limit error appears when I try to translate.
Comment #405
wroxbox CreditAttribution: wroxbox commentedIn my findings $entity_langcode is emtpty/null and the subform fields get wrong langcode.
Node is entity translatable
Node has translatable field (field_short_description)
FC is translatable (field_deployment)
FC items are translatable
inside FC I reuse field_short_description as translatable field too.
I have master language FI and translating entity as SV.
By
gives forms
form-type-textarea form-item-field-deployment-sv-0-field-short-description-fi-0-value
Changing to
gives form as
And now all data is saved property to database and editing works fine.
Comment #406
joseph.olstadThis patch might fail as I re-enabled a portion of a test said to have known to fail. However it might also succeed as I made the change suggested in comment #405 by wroxbox.
In addition I removed the preceeding call to entity_language as it is no longer used in that said function.
See interdiff
If this fails I'll restore the original field_collection.test asap, otherwise if it works, then great.
Comment #407
jmuzz CreditAttribution: jmuzz commentedThanks for the update!
The issues with data deletion still haven't been addressed so I'm setting the status back.
Comment #408
joseph.olstadHi Jmuzz, actually according to the field_collection.test it does address the data deletion.
See this line in field_collection.test from the patch in 406
$this->assert(empty($fc_items), t('The field collection item has been removed from the database.'));
I activated this assertion and it passed according to SimpleTest.
What other data deletion might you be referring to? If the test is missing, can you please add it?
Comment #409
LendudeBasically #405 rolled into the patch. For me it was that when adding a new translation the default values were null instead of the values in the original host entity.
I opted to take the language of the host entity, which sounds logical to me, but not really into this issue enough to be sure that it is. But it did solve the issue for me.
Sorry, no time to write a test for this at the moment.
Comment #410
LendudeAnd now with the new file added to the patch....
Looks like joseph.olstad tried to do this too in #406, but the changes in that interdiff don't appear to be in the patch?
Comment #411
colanStill works well for adding new content/translations, but we need reviews on everything else.
Comment #412
jmuzz CreditAttribution: jmuzz commentedThe patch can destroy data during the update in field_collection.install .
See #359 and #361 for an explanation and a reference to some test data that can be used to reproduce.
Comment #413
kedramonHi all,
Found an issue,
basic setup:
drupal (7.37)
entity_translation (7.x-1.0-beta4)
field_collection (7.x-1.0-beta8)
Add field collection to node, with unlimited values, and enable translation for field collection. Filed collection fields: some name (text), term auto-complete (term_reference), not translated.
Create node with any content, add minimum two field collection item. After save, create translation, try to add or edit field collection, as result
this happens in second item of field collection.
Anyone have this issue?
Regards,
Vova
Comment #414
hwasem CreditAttribution: hwasem commentedI was able to get patch 410 to Mostly work for me. There were error messages about translation.handler_factory.inc after clearing running update.php, but clearing the cache seemed to fix that.
Entity Translation - 7.x-1.0-beta4
Field Collection - 7.x-1.0-beta8+11-dev (2015-Mar-26) + patch in #410
My config:
Content type that is translatable with a mix of fields that are translatable and non-translatable
Field Collection that is untranslated
-- title sub field - translatable
-- node reference - untranslated
Entity Translation config - admin/config/regional/entity_translation
- under Translatable Entity Types - enabled Field Collection items
I was able to translate a node (english is default) into two languages. The title subfield is correctly saved in each language and is not overwriting other language values. This is huge.
The only thing not working is when I EDIT a node, the field content for the source language is not consistently being displayed when I edit a Spanish node, for example. This is not always missing and I'm not sure when it does and when it doesn't work. The display view of the same Spanish node IS showing the English content, it is just not always carrying that English text through to the edit screen.
Comment #415
maxplus CreditAttribution: maxplus commentedHi,
Thanks for the effort.
I'm also running:
Entity Translation - 7.x-1.0-beta4
Field Collection - 7.x-1.0-beta8+11-dev (2015-Mar-26) + patch in #410
When I try to translate a node containing a translatable field collection, I get a memory error:
Comment #416
omarlopesinoPatch #410 worked for me in most case except when i tried to delete items from a multiple field collection.
I used this versions of field collection and entity translation:
Entity Translation - 7.x-1.0-beta4
Field Collection - 7.x-1.0-beta8+11-dev
I used it with a content type which has a field collection non translatable with translatable fields.
I can create values when the field collection item was multiple, but i can't delete the items.
Reading the message I saw that is a nesting problem.
Attach message:
Comment #417
omarlopesinoI debugging and i think i found a solution for being able to delete items in a multiple field collection.
I attach the patch.
Comment #418
omarlopesinoComment #419
omarlopesinoFixing patch.
Comment #420
jmuzz CreditAttribution: jmuzz commentedThe patch can destroy data during the update in field_collection.install .
See #359 and #361 for an explanation and a reference to some test data that can be used to reproduce.
Comment #421
omarlopesinoI've seen the issue related with nested field collection and i did a fix in field_collection_field_update.
When the items of a field collection are updated they are removed when they are unused, but don't check if currently the same item is being used in other languages.
I attach the patch.
I attach too the database i've used with a content type which contains a field collection nested (field_collection_tests) multilanguage.
@NOTE: i do the interdiff over #410 because i commit a mistake in my latest patch.
Comment #422
omarlopesinoComment #423
omarlopesinoComment #424
Johnny vd Laar CreditAttribution: Johnny vd Laar at ezCompany commentedI'm testing the patch from #423 and also #410 with this setup:
Node with translatable FC (unlimited) and untranslatable fields. So each translation gets a new FC id. When I create a new node all works well and the FC gets the right language. When I create the translation then I get an infinite loop because the field collection cannot seem to find it's language:
When I set the field collection as single instead of unlimited, all works fine.
Comment #425
Johnny vd Laar CreditAttribution: Johnny vd Laar at ezCompany commentedAlso seems that setting it to 5 values works as well. So the problem is only for unlimited. Switching off "Hide blank items" doesn't influence this.
Comment #426
Johnny vd Laar CreditAttribution: Johnny vd Laar at ezCompany commentedI had a problem in the upgrade path of my nodes. I have a node with a field collection. The fc is not translatable it has 2 fields 1 translatable and 1 not translatable. The data of the untranslatable field was gone after update hook 7007. This is caused because the copyTranslations function does not check if the field is translatable. Attached patch fixes this. Patch is based on #421.
Comment #428
Johnny vd Laar CreditAttribution: Johnny vd Laar at ezCompany commentedHmm... perhaps this works.
Comment #429
irowboat CreditAttribution: irowboat commentedInitial testing says #428 is solid on a site with entity translation.Patches clean dev version fine, but database update does not work.
This line is the only one regarding translation.handler.field_collection_item.inc:
edit:
Manually adding the file and getting content for it from #426 makes database update work.Error on database update: "Unable to save a field collection item without a valid reference to a host entity."
Comment #430
Johnny vd Laar CreditAttribution: Johnny vd Laar at ezCompany commentedIndeed that file is not in the patch. I'll add it again.
Comment #431
subhojit777#430 is working for me. I have not tested thoroughly (using views, etc.), but I can enable translation for field collection field and create translation for nodes.
Comment #432
omarlopesinoTesting the usages of the field collection translatable, I've seen something that I don't understand.
Having one field collection untranslatable and field collection entity translation activated, when I save the host entity (translatable node),in the entity_translation table which stores translatable entities saved, the field collection is saved in that table only with the current language when normally is saved in the languages which the entity is saved.
@NOTE: the content type which belongs the field collection have set current language as default language, I don't know if it can influence.
Comment #433
drclaw CreditAttribution: drclaw at Fuse Interactive commentedThe patch in comment #430 applies cleanly and appears to work. I was having some trouble initially with the db update as well (mentioned in comment #429 by @irowboat), getting the "Unable to save a field collection item without a valid reference to a host entity." error. It was only happening on one of my field collection types. For some reason the host entity wasn't being attached properly to the field collection item. I thought maybe it had something to do with the fields on the field collection type being translatable before applying the patch, so I disabled translation on them and ran the update again and it worked. However, I had other field collection types that also had translatable fields before the update so I can't really tell you why this fixed it... I wish I could offer some more insight but that's all I have for now.
Comment #434
robin.ingelbrecht CreditAttribution: robin.ingelbrecht commentedWhen I try to translate a node containing a translatable field collection, I get a memory error.
My content type consists of field collections in field collections.
I already upped the memory to 1024 MB, still the same error.
Comment #435
subhojit777I am updating database and am getting this error:
PHP Fatal error: Call to undefined method FieldCollectionItemEntity::copyTranslations() in /Applications/MAMP/htdocs/mysite/sites/all/modules/contrib/field_collection/field_collection.install on line 355
Comment #436
nicrodgersThe patch in #430 applied cleanly for me, and I no longer get errors when trying to translate nodes with field collection fields with multiple values. DB update worked fine, too.
Thanks!
Comment #437
das-peter CreditAttribution: das-peter commentedJust found a possible recursion in
EntityTranslationFieldCollectionItemHandler::getLanguage()
. Currently the method calls$this->entity->langcode()
, which subsequently callsEntityTranslationFieldCollectionItemHandler::getLanguage()
, and this calls$this->entity->langcode()
, which subsequently callsEntityTranslationFieldCollectionItemHandler::getLanguage()
...You get the idea ;)
@robin.ingelbrecht Please try the updated patch.
Comment #438
Anonymous (not verified) CreditAttribution: Anonymous commentedThe patch from #430 doesn't apply properly for me. It creates a new directory called 'includes' outside the drupal root directory. The new 'includes' directory contains one file: translation.handler.field_collection_item.inc
I used PHPStorm to apply the patch. When I try to apply the patch with git, it appears to work but doesn't change anything.
Comment #439
daniel.nitsche CreditAttribution: daniel.nitsche as a volunteer commented@douglasgough are you patching against dev? Seems ok to me. I ran this:
If it's still not working for you, I'd suggest pasting in the exact commands you ran.
Comment #440
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks daniel.nitsche. It appears that PHPStorm doesn't apply this patch properly. I followed your instructions and the patch applied properly.
Comment #441
kallehauge CreditAttribution: kallehauge at Reload commentedOur override of the getLanguage() method in translation.handler.field_collection_item.inc can create a loop where it will keep calling itself. That made me actually look at the method. Why do we even need it? We get the correct language code from the original getLanguage() method and are only creating extra overhead/complexity for ourself by maintaining it ourselves. – It's introduced in #45 if you want to look at the source of the override.
Edit: I figured why we need it. When translating directly (/admin/field-collection/field-right-column/xxx/edit/...), we only get the original language of the entity it belongs to, but the method still fetched it "wrong" and it could cause a loop. So our main problem atm is language detection. – Should we fetch it from the URL? Might seem like our only solution, and then default to ::parent ?
Comment #442
entendu CreditAttribution: entendu for eBay Enterprise commentedNested field collections are not translating properly when the highest-level FC is 'unlimited' cardinality and more than one instance exists.
On a fresh D7 install, I set up FCs like this on the Article type:
When translating a node that has only ONE "Top level" FC instance, it works. But, if I "add another", it chokes with these messages when saving a new translation:
I configured entity_translation to translate fields, etc etc. Enabled modules in this list. Using field_collection patch in #437. I am including a DB dump (drupal login is admin/admin) and the sites/all/modules directory from my test environment, see attachments.
Comment #443
entendu CreditAttribution: entendu for eBay Enterprise commentedFWIW, it seems my issue might be the same as https://www.drupal.org/node/1344672?page=1#comment-9560475
Comment #444
entendu CreditAttribution: entendu for eBay Enterprise commentedUpdating summary.
Comment #445
tim.plunkettThere are a lot of unrelated changes here. Can they be removed please?
I don't know multilingual stuff well enough to really review the rest. :(
Comment #446
idebr CreditAttribution: idebr as a volunteer commentedOn a Drupal installation without entity_translation installed this results in a fatal error 'Call to undefined function entity_translation_get_handler()' when updating.
Comment #447
colanI took #437 and fixed #445 and #446.
Are #420 and #441 still issues?
Comment #448
joseph.olstadAfter a careful review I confirm that Colans fixes for #445 and #446 are good.
Can we commit this please and open new issues for #420 and #441 (if necessary).
RTBC+
Comment #449
Soul88Guys, has anyone tested this patch for "by nodes" translation? Some previous patches were breaking it and I do not have time to properly test it right now.
If it is still the case, I don't think it should be commited as this type of translation is already used by many sites in prod, and so we can't let them break with the update.
Comment #450
joseph.olstadHi Soul88, in response to your comment#449, I suggest we commit this to a 7.x-2.x branch instead of the 1.x branch.
Then if someone likes they could backport this to 1.x later or just push forward on 2.x
Comment #451
Soul88Well, I'm not a field_collection module maintainer, but I still don't like the idea of trading support of one translation type for another. If that's the case.
Comment #452
DamienMcKennaIf there are still problems with the workflow / data structure might I suggest extending the tests to be more specific as to what should happen in more scenarios?
Comment #453
joseph.olstadSoul88 , this will work with node translation, no need to copyTranslations in that case (because each node will has it's own field collection with its own entity_id when using node translation).
For field translation using entity translation (ET) is really what colan fixed.
In the case that entity translation is NOT enabled, copyTranslations returns null because $host_et_handler will be null or else entity_translation is not enabled and it will return null which makes perfect sense when using node translation because each field collection will use language undefined when using node translation.
When field translation is enabled and the $host_et_handler is set (ET is configured) the fields will be copied using the copyTranslations function
@colan , *EDIT* thanks to "Scott Robertson" for clarifiying this
I noticed issue with the latest code, a drupal code standards issue, copyTranslations is using caMel case, drupal coding standards tells us to change the copyTranslations to copy_fc_translations would probably be better as this is a public function and we don't want to step on other function names just in case copy_translations is already used by another contrib or core module copy_fc_translations would be a more specific name (less chance of name space issue). We might want to run a quick code sniffer and "coder review" on the patch before committing just to clean up some minor issues.Comment #454
Scott Robertson CreditAttribution: Scott Robertson commented@joseph.olstad, are you referring to the method name (copyTranslations) itself? If so, class methods are supposed to be named using lowerCamel:
https://www.drupal.org/node/608152#naming
Comment #455
nadine_cz CreditAttribution: nadine_cz commentedI've tested with #447, and ran into a small problem (I was using #187 (with wetkit) prior and it had the problem as well).
My use case: Create a node and field collection (with translations) programmatically.
Issue: The copyTranslations overrides the translations I've passed in.
Fix (?): By checking that the translation is set and not overriding...my use case now works.
(line 492 ish - field_collection.entity.inc)
Comment #456
colanLet's get that additional check added, and then we should be good to go.
Comment #457
joseph.olstad@nadinecz, I was going to take your word as gold and do as you say but your code snippet comment doesn't make sense to me.
you've written:
but the code in the snippet says:
if(!isset(BLAH)) {
your comment says //if set
so what do you think the code should be? if set or if is not set?
patch 487 gives this on line 492:
so what are you proposing at line 492? it looks like you're proposing to do the same thing as "if isset()" on the else ?
Comment #458
nadine_cz CreditAttribution: nadine_cz commentedhey @joseph.olstad
The struggle with being coherant…it’s real.
My comment is misleading (apologies). I’m trying to say: if I’ve already set the translation for the FC field, please don’t override it with the source language. If you do, I’m stuck…..
Maybe a bit more background would help (?)
I have a case where I’m creating a node with a field collection programatically…. The node is language_none, but I have a field in the FC that’s multilingual. So, a “section” (node) with “questions” (fc) – the question field is displayed in EN or FR )
Please note, if this is too specific a use case, I can patch it locally and move on – no worries. Alternatively, I can open another ticket independent of this one so that the #447 patch can move forward as there are changes in there that shouldn’t be held back by this use case.
If it does get included, feel free to drupalize that comment….
Comment #459
joseph.olstad@nadinecz, here is the updated patch with your code with the interdiff, I added some descriptive comments.
The interdiff will show you the differences.
@nadinedz, @colan, can you please review?
Comment #460
nadine_cz CreditAttribution: nadine_cz commentedLooks good @joseph.olstad - thanks!
Comment #461
colanSomeone needs to test nested field collections, as per #359 to see if there's still data loss, and I'm afraid I don't have an environment set up for that right now. This shouldn't be
turned greenRTBCed until we can confirm that this is no longer a problem.Comment #462
idflood CreditAttribution: idflood as a volunteer commentedMaybe this is not related to the patch in #459 but I've some issues when translating the field collection. To reproduce:
- Create an unlimited field collection with multiple fields.
- The fields inside the collection are not translatable but the field collection is. This way i could have 2 items in english and 3 different one in german for instance.
- Create a node and make 3 items of the collection.
- Translate the node, remove the second item of the field collection.
The problem is that it also remove the third item of the collection, and i have the following notices:
edit: Reproduced the error on a clean install and copied the new notices and warning. The error about numbers is because I'v added a float subfield with a min/max. The value I entered is valid but when creating a new translation if I remove the field collection items and add new one the validation seems to be buggy.
Comment #463
joseph.olstad@idflood, I've re-read your use case a few times, I'll have to try to reproduce your steps myself, maybe we can write a simple test for it.
Is it safe to assume that you've applied the patch 459 to the latest dev from march 2015?
Comment #464
joseph.olstadHello @idflood, I installed a recent dev version of a distribution of Drupal that I use often and upgraded field_collection to the latest dev and applied patch 459, then I repeated your steps verbatim with the unlimited field collections, I could not reproduce the errors that you mentioned.
Seeing as the errors you observed came from drupal core I suggest that you upgrade your entity_translation module and make sure to upgrade your drupal core to the latest version and then install field_collection the latest dev and apply patch 459. There may be some other contrib module that you may want to upgrade, I suggest also upgrading your ctools module to the latest stable version. Once you do this your error should go away.
from my perspective this is
RTBC +1
Comment #465
idflood CreditAttribution: idflood as a volunteer commented@joseph.olstad thanks for the quick response. Maybe it's a small configuration difference since I a did a clean install with the following:
- Drupal 7.39
- ctools 7.x-1.9
- i18n 7.x-1.13 (Content translation, Field translation, Internationalization, Multilingual content, String translation enabled)
- Field collection, cloned 7.x-1.x from git today and applied patch in #459
- Entity API 7.x-1.x (dev version)
- Entity Translation 7.x-1.x (dev version)
- Added a second language and in the "Detection and selection" tab enabled the UI method for both UI and Content language detection.
- In Basic page content type add a new field collection with "Embedded" widget, unlimited values and the field translation checkbox checked.
- when editing the content type I "Enabled, with field translation" in Publishing options >Multilingual support.
- in the field collection added one simple text field and a float field with min 0, max 100 and made it required. For both fields the "Users may translate all occurrences of this field" is not checked.
- created a page in english with 3 items in the field collection, saved.
- clicked the translate tab, and added a translation.
- clicked the remove button from the 2nd item. No errors but the third item is removed too.
- clicked "Add another item" and entered valid values.
- clicked save, the errors shows up and the translation is not saved.
edit: I tested again this morning but still have the same issue. This time I cloned the latest version of entity and entity_translation from git but the error is still the same.
I also tried to enable the field translation on the collection AND the subfields. The result is a little different, the subfield content isn't copied when translating but I still have the same errors.
Also the issue happens only if the FC has unlimited values. With a fixed number of items it seems to be working fine.
Comment #466
joseph.olstadHi @idflood, ok, I confirm, I can reproduce the issue.
using a float as you did got the same error as you, then I removed the float from the collection and changed it to an integer.
replacing float with integer field I get some Undefined index warnings from core, but the functionality works everything works as expected.
Heres the warnings:
Notice : Undefined index: field in field_widget_field() (line 578 in modules/field/field.form.inc).
Notice : Undefined index: instance in field_widget_instance() (line 603 in modules/field/field.form.inc).
Notice : Undefined index: field in field_widget_field() (line 578 dans modules/field/field.form.inc).
Notice : Undefined index: instance in field_widget_instance() (line 603 in modules/field/field.form.inc).
Here's what the database says at this time:
select entity_type, bundle, entity_id, language, field_fc_value, field_fc_revision_id from field_data_field_fc;
|entity_type| bundle |entity_id |language|field_fc_value|field_fc_revision_id|
|node | basic_page| 6 | en | 18| 93|
|node | basic_page| 6 | fr | 21| 96|
|node | basic_page| 6 | en | 19| 94|
|node | basic_page| 6 | fr | 22| 97|
|node | basic_page| 6 | en | 20| 95|
|node | basic_page| 6 | fr | 23| 98|
select entity_type, entity_id, revision_id, bundle, language, field_text_value from field_data_field_text;
|entity_type |entity_id|revision_id| bundle |language|field_text_value
|field_collection_item| 18| 93| field_fc| und |test en 3 first field collection
|field_collection_item| 19| 94| field_fc| und |test en 3 second field collection
|field_collection_item| 20| 95| field_fc| und |test en 3 third field collection
|field_collection_item| 21| 96| field_fc| und |test fr 3 premier field collection
|field_collection_item| 22| 97| field_fc| und |test fr 3 deuxième field collection
|field_collection_item| 23| 98| field_fc| und |test fr 3 troisième field collection
select entity_type, entity_id, revision_id, bundle, language, field_integer_value from field_data_field_integer;
|entity_type |entity_id |revision_id |bundle |language |field_integer_value |
|field_collection_item | 18 | 93 |field_fc |und | 3 |
|field_collection_item | 19 | 94 |field_fc |und | 4 |
|field_collection_item | 20 | 95 |field_fc |und | 5 |
|field_collection_item | 21 | 96 |field_fc |und | 3 |
|field_collection_item | 22 | 97 |field_fc |und | 4 |
|field_collection_item | 23 | 98 |field_fc |und | 5 |
looks good in the backend, and then I remove the second field collection, it only removes the second, this is good, I think your issue with the float field is because of the failed validation on floats (integer fields don't have the validation problem).
Going back to the float issue, core validation prevents us from saving the translated field collection with the float field, the warnings and validation issue is comming from core. We need to isolate the issue, it's not obvious if its our patch that is causing it (if so, where?) or if it's something up in the "entity" module. I'll see if I can try one more test and try to isolate the issue more.
Comment #467
joseph.olstadFor someone else that wants to debug this, have a look in field_collection.module
function field_collection_field_widget_embed_validate
this line should be removed:
the variable $instance is never used in this function so remove it, useless call.
Then the next line,
$field =
this variable isn't used until much further down in the function but is used.
The function that is called on this line calls a drupal core api field_widget_field() , this core api doesn't like what we're passing into it.
This is where I ran out of time.
At this point we should commit the patch and deal with this use case in a new issue? Or do the maintainers suggest we keep plugging away on this mega-issue?
*EDIT* the warnings in the test from the previous comment when using "integer" instead of "float" field likely provide us with clues that may help figure out the "float" issue (when unlimited fc values with translation turned on on the fc, but not on the fields inside the fc).
Comment #468
idflood CreditAttribution: idflood as a volunteer commentedI continued to dig a little more inside the error and it seems that the problem may be with an "invalid" form state. The field_widget_field will look for something like this in the form state: $form_state['field']['#parents']['field_collection_name']['lang']['index']['#fields']['subfield']['lang'].
When the error happen the $form_state looks like this:
As you can see the second field collection item only has 'array_parents' defined but the first one has also 'field', 'instance', ...
Comment #469
joseph.olstad@idflood, the closest similar issue to what we're observing with an unlimited field_collection fc translation enabled that contains a float field (field translation disabled) where the 2nd, 3rd or Nth field collection float value fails validation is this:
Cannot add entity with decimal or float numbers
In this case the solution was a patch titled "allow form_state to be altered"
I tried to add two and two together here but have not yet come up with a solution.
The bottom rectangle below is what core (field.form.inc line 578) is failing to validate . The top rectangle is the first float that IS correctly validated. The Nth float (after the first) always looks like the bottom rectangle.
Comment #470
scotwith1tSorry if this is at all off-topic, but I came here from #1999802: Related source suggestions for field collections, which essentially deals with translations of field_collections in the tmgmt module. Using the latest dev with the latest patch and the dev versions of both entity_translation and tmgmt, I was able to export a node with the field_collection entities as part of the XLIF translation file. When I got the translation back and imported it, the translations are in the instance table but not showing up on the node at, for example, /es/node/1. Looking in the devel tab for the node, they are not in the field's array keys, only have 'en' as a key, no 'es' (translation file was for en > es). Not sure if this is a problem in tmgmt (likely) or just in the field_collections translatability overall.
Comment #471
joseph.olstad@scotself , after reading your comment it's unclear what steps were made to reproduce your use case.
For instance, you mentioned; Using the latest dev with the latest patch and the dev versions of both entity_translation and tmgmt
but it was not mentioned what version of field_collections you were using. This issue is concerned with field_collections so it's important that we know what version of field_collections you were using and what patch you were using (the latest patch for entity translation support on field_collections is patch #459).
Also, if you could be so kind as to provide steps to reproduce your issue with a description of the configuration of your fc and fields inside your fc and also what sample data you used and what translation options you used and your content type configuration.
This patch is almost ready, I believe that @idflood has identified one of the few remaining edge cases that we'd like to solve before committing this patch. This issue is getting rediculously long so we'd like to really focus on the remaining work.
Comment #472
scotwith1tSure. Latest dev with latest patch means latest dev of field_collections (as of the moment of my comment, pulled down the dev snapshot) and the latest patch being the last one posted, namely yours in comment 459.
Our setup is as follows:
A simple content type with a field collection, which consists of an image field and a body field.
Exported a single node, including field collection entities attached to it.
Export worked great, import seemed to work fine but no field collections were on the translated node.
Looked around in the DB and found that my field_data_field_collection_img and field_data_field_collection_body fields as well as the revision fields for both were indeed populated but there were no entries for the field_data_field_collection field itself, which contains the 2 fields above.
I don't know if I'm describing this sufficiently or not. It may not even be a problem with field_collections translations specifically anyway, it could be with entity_translation or with tmgmt. No idea.
Comment #473
joseph.olstad@idflood,
I suspect we should run your test use case and debug this section of code starting at line 1400 (latest dev with patch 459 applied) of field_collection.module
debug this function , I believe the answers lie in there.
to be continued...
Comment #474
joseph.olstadWe really need to finish this issue. I just looked through the patch again and the opportunity to solve the remaining issue outlined by @idflood definately lies in the following section of the patch:
re-run @idflood use case and debug the above lines of code. (use devel with dpm() or debug() statements)
would be nice to have a simpletest for this use case but the @idflood steps are easy enough to follow and I was able to duplicate them.
Who is going to be the hero and put this into the end-zone?
Comment #475
joseph.olstadsetting this back to "needs work", while patch 459 does pass all simpletest tests we still need to fix the use case scenario outlined by @idflood , once this is done we should be able to commit this patch (for the love of a higher power, please alien master, have pity on us earthlings and send some alien brain power down to finish this off)
Comment #476
joseph.olstadOk, debugged @idfloods' use case pretty hard,
in the case that the field_collection is using multilingual with field translation but the items inside are not
the solution looks to me now like in field_collection_field_widget_form
I was able to get the correct value for the language using this:
however now its a matter of figuring out when this language value should be used in place of what is in
however its a bit tricky because the initial values we want are actually the ones from the source language , (to populate the text fields for data entry) , but we want them to save into the correct language value array structure. I'll have to do more debugging to figure this out.
I did some tests but they all failed so far, need to spend a bit more time on this, I think I'm pretty close to finding a solution , to be continued.
Comment #477
Sergii CreditAttribution: Sergii commentedHi!
I'm testing related issue #1281974: Missing bundle property on entity - related to translations. The latest fix #1281974-110: Missing bundle property on entity - related to translations developed in there included into the latest patch here #1344672-459: Field Collection: Field translation (entity_translation) support.:
Still, nested field collections are failing when I add new translations and the original collection field has more more than one item.
I debugged this a little – and it turns out that sometimes $entity argument passed to entity_extract_ids() function passed from field_attach_form_validate( ), field_collection.module:1428 is NULL. It happens when the both if and elseif clauses (see above) are FALSE so $field_collection_item (which later passed as $entity to entity_extract_ids()) never gets set.
Hence the error:
EntityMalformedException: Missing bundle property on entity of type field_collection_item. in entity_extract_ids() (line 7844 of /var/www/dev.dosomething.org/html/includes/common.inc).
Shouldn't there be a final else somewhere? Or is there a logic error in retrieving $field_collection_item from the form state?
With best regards,
Sergii
Comment #478
joseph.olstadHi sergii, see my comment #476 about the language value, in the case of unlimited fields, the second field fails to work correctly in the translation because the logic isnt expecting what the form gets populated with on page load . Debugging showed me the problem, just havent yet had time to code a solution, a bit tricky because we need logic to kick in for second field of unlimited fields but yet still work for first field value. I would love to have a solution this weekend, we shall see. Review my last comment and this will get us on the same page.
Comment #479
twistor CreditAttribution: twistor as a volunteer commentedSo this seems wrong. Even if translation is enabled, it's still valid for the language to be set to LANGUAGE_NONE.
Comment #480
joseph.olstadI spent a few hours testing out unlimited field collections and debugging.
now I'm zero'ing in on logic ran after checks for field cardinality, this handles the "unlimited" capability
$field['cardinality'] == FIELD_CARDINALITY_UNLIMITED
so far all I can tell is when you first press "add" translation for a node with unlimited field collections (in my case 3 or 4) I did a lot of dpm looking up, the first field_collection parent has the second language (in my case 'fr') language code.
in the subsequent field_collection parent it is back to 'en'
For whatever reason the second field_collection isn't handled correctly in the translation whereas it is handled correctly in the original language.
to fix this, focus on the sections of code where FIELD_CARDINALITY_UNLIMITED is checked, like right after.
That is all. The related code is in field_collection.module .
BTW, patch 459 still applies cleanly to the latest dev build and newest release.
Comment #482
thinkingcap CreditAttribution: thinkingcap commentedAs @twistor pointed out in #479, the following code in field_collection_field_update()
results in data loss when editing and saving, with the host_entity set to LANGUAGE_NONE.
I've commented out this code for the time being and things are working. What is the purpose of this?
Comment #483
GaëlGI can confirm that #479 and #482 are right:
7.x-1.0-beta10 + #459, when using an optional translatable infinite-valued host field with untranslatable collection fields, I get this :
* create a node in "en" with a field collection filled : OK
* create a node in "en" with no field collection and then edit it to add a field collection : OK
* create a node in "und" with a field collection filled : OK
* create a node in "und" with no field collection and then edit it to add a field collection : BUG the field collection isn't added at all
If I comment out what thinkingcap mentioned in #482, I get OK for these 4 scenarios. I'll do some more tests with other scenarios.
Comment #484
GaëlGI found another bug. Here's the scenario, but the bug might also exist with a simpler one.
You'll get the same content in the two english collections. I guess it only applies for a multivalued host field, because of the empty collection which is added in the form by default.
And here's the patch (it also includes #482). I'll do more tests with my config (optional translatable infinite-valued host field with untranslatable collection fields) to see if I can still find bugs with this new patch applied.
Probably still needs work to handle the "float bug" (#467)
Comment #485
JuliaKoelsch CreditAttribution: JuliaKoelsch at Spry Digital, LLC commented@GaelG,
I tried applying your patch to the latest dev version. It applies cleanly, but I am getting an error:
PHP Fatal error: Call to undefined function field_collection_is_empty() in ...field_collection.module on line 1405
I don't see that this function is defined in the source code. Can you provide some guidance? Prior to your version of the patch, things were working well for me.
Thanks,
Julia
Comment #486
pierregermain CreditAttribution: pierregermain commented@GaelG,
applied your patch to beta-10 of Field Collection and still get these kind of messages when adding a language to a Content Type that uses Field Collection:
Warning: array_filter() expects parameter 1 to be array, string given in field_collection_item_is_empty() (line 591 of /sites/all/modules/contrib/field_collection/field_collection.module).
I would also like to know what kind of patches we need to make Fiel Collection work(around) in multilang.
My situation is as follows:
I create a Content Type with Field Translation that has a Field Collection
- I create a node in Spanish of that Content Type
- I translate the node to English, the data of the Field Collection in Spanish gets lost
- I again enter the data of the Field Collection in Spanish and English. Seems to get updated but with the error posted before in this post.
Comment #487
GaëlG@Spry_Julia Yes, there is an error in my patch, sorry. It's
field_collection_item_is_empty()
, notfield_collection_is_empty()
. Looks like pierregermain figured it out on his own.Here's the correct patch. I tested it against scenario #484, both with beta10 and latest dev. I also join my test file for Firefox Selenium IDE, so that anyone can adapt it to its website.
@pierregermain I'll try to reproduce your bug.
Comment #488
GaëlG@pierregermain I could not reproduce your bug on 7.x-1.x + #487, when using an optional translatable infinite-valued host field with untranslatable collection subfields. Here's my Selenium test.
You might be using another configuration?
Comment #489
GaëlGOops, I just find out that I forgot to add #482 in #487.
DO NOT USE THIS PATCH OR PREVIOUS PATCHES OF MINE (see #502 for why)
Comment #490
pierregermain CreditAttribution: pierregermain commentedHello GaëlG,
Thank you for your time. I use 2 Fields on my Field Collection, both translatable and infinite (but I have done some test putting an limit also).
I will try your last patch then. Should I use an other patch before applying patch #489 ?
Comment #491
pierregermain CreditAttribution: pierregermain commentedI have just used patch #489 ... seems to work when:
- using groupings for the fields
- let the last grouping field in the hierarchy without translation.
Oops, I just seen that when saving the content for the first time the information of the "father" gets lost.
Comment #492
GaëlGComment #493
joseph.olstadlooks like 1344672-489.patch is worth reviewing.
Comment #494
joseph.olstadComment #495
joseph.olstadI repeated the use case , translate unlimited collection with float
it resulted in:
then red boxes around the second, third and fourth translation of unlimited collection. Cannot save the translation of second, third, fourth unlimited collection
Comment #496
sumachaa CreditAttribution: sumachaa commentedAuto population for field_collection fields is not working for 3rd language.
Below steps were used to replicate this
Testing was done with patch #489
This is working fine if the field_collection field (address) is having translation enabled.
Is this the correct way of resolving this issue?
Comment #497
GaëlG@sumachaa I don't know if it's THE correct way to do, but that's the way I and many others use.
Comment #498
mErilainen CreditAttribution: mErilainen at Wunder commentedI'm having problems updating field collection values. I can add for example three field collections fine, but when I update content and change field collection values, all the field collection references seem to be the same after update. So I have the same values three times.
Comment #499
GaëlG@mErilainen Are you sure you enabled translation on subfields?Don't mind, I read and spoke too fast.
Comment #500
mErilainen CreditAttribution: mErilainen at Wunder commentedI have been trying to debug this and I think it happens in field_collection_field_widget_embed_validate() because of
Using
works better, but the field collection values seem to be empty when editing content again.
Further investigation needed...
Comment #501
betoscopioI tried the patch in #489 and I found the following problems:
When I run update.php (with drush) I got this messages:
The changes seems not fully applied (because the error), if I run the update script two more times I got the same error.
If I run the script a fourth time I see no error messages and changes are not pending. I checked this in two copies of the website, the behaviour was the same.
After apply the patch and activate field_collection as a translatable entity I have the following behaviour:
- In a field collection with 2 fields (one translatable and one not) with a fixed number of 8 items
- Before run multiple times the update.php I had problems becuase some values were empty (the translatable field)
- After run update.php for fourth time (no more error messages) I have no problems with this field.
Comment #502
GaëlGDo not use my last patch! It happens to work in many cases when node revision is enabled (which was the case in all my tests), but the data gets corrupted.
It's hard to find a use case where a bug happen, but if you add a new collection to an existing node, you get a node referencing the same collection with two different revision ids, which is wrong and could lead to data loss, even if the data do not seem corrupted in the interface.
I have no idea what the hell can happen if node revisions are disabled, but this is probably what happened to some of you lately.
I'm working on it again...
Comment #503
GaëlGHum... And now it looks like I cannot reproduce the bug #483 when using latest dev+#459+#482. Conclusion: #489 is not only buggy and risky, it's also useless... This issue will make me mad.
Comment #504
sylus CreditAttribution: sylus commentedPatch based on: #1344672-459: Field Collection: Field translation (entity_translation) support. and on Twistor's comments about unsetting the langcode in #1344672-479: Field Collection: Field translation (entity_translation) support.
Setting to needs review just to trigger DrupalCI.
Comment #505
joseph.olstadaccording to the automated testing settings, 7.x issue testing is currently disabled, we'll have to get a maintainer or co-maintainer to enable automated testing for 7.x if we want to test patch #504 against head.
Comment #506
joseph.olstadOk I ran the tests in simpletest by enabling the simpletest module and going to
admin/config/development/testing
Expand field ui
and test field_collection
Field collection
Tests creating and using field collections.
140 passes, 0 fails, 0 exceptions, and 31 debug messages
Field collection content translation
Tests using content under translation.
26 passes, 0 fails, 0 exceptions, and 9 debug messages
Field collection entity translation
Tests using content under translation with Entity Translation.
211 passes, 2 fails, 1 exception, and 45 debug messages
Notice:
Undefined index: de Notice field_collection.test 1144 FieldCollectionEntityTranslationTestCase->getFieldValues()
Other:
Value NULL is equal to value 'Translatable DE Mod'. Other field_collection.test 1195 FieldCollectionEntityTranslationTestCase->testEntityTranslation()
The field collection item has been removed from the database. Other field_collection.test 982 FieldCollectionEntityTranslationTestCase->removeTranslationForm()
Comment #507
joseph.olstadRepeated use case based on what was described by idflood
gives the following message when adding translation of unlimited fc :
Notice: Undefined index: field in field_widget_field() (line 578 of /modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /modules/field/field.form.inc).
Warning: preg_replace(): Compilation failed: range out of order in character class at offset 14 in number_field_widget_validate() (line 389 of /modules/field/modules/number/number.module).
Only numbers and the decimal separator () allowed in .
Notice: Undefined index: field in field_widget_field() (line 578 of /modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /modules/field/field.form.inc).
Warning: preg_replace(): Compilation failed: range out of order in character class at offset 14 in number_field_widget_validate() (line 389 of /modules/field/modules/number/number.module).
Only numbers and the decimal separator () allowed in .
Comment #508
Kristen PolI have confirmed that nested limited (e.g. max=5) field collections are working with the patch but unlimited is not. I see similar errors to #507 when the nested field collections are unlimited.
Comment #509
Kristen PolWe are looking for someone to get this patch over the finish line. I've contacted a couple people directly but didn't get any response. If you are willing and able to get this patch working asap (paid consulting), please contact me through my profile page. Thanks.
Comment #510
chrisdarke42 CreditAttribution: chrisdarke42 at Hook 42 for SunPower Corporation commentedSo one issue that doesn't get resolved by the previous patches, seems to be the depth issue,
field_collection_field_widget_embed_validate only seems to work to a certain depth, and I have cases where nested field collections within other field collections just cause errors on translation.
This adds an implementation of drupal_array_get_nested_value to get the correct field collection regardless of depth for the validation.
Comment #511
Kristen PolWe have a new patch that is working for us that @loopduplicate and @chrisdarke42 fixed. We'll try to get that up very soon.
Comment #512
loopduplicateWe are having luck using the patch from #510 combined with the patch from #6 in https://www.drupal.org/node/2339315#comment-10848466 .
With these two patches, everything works for our set up. The structure is:
* A translatable node
* A translatable field collection in the node
* A non-translatable field collection in the field collection
None of the fields in the field collections need to be set to translatable.
Hope this helps.
Regards,
Jeff
Comment #513
joseph.olstadRTBC+1 as described by loopduplicate
GREAT WORK EVERYONE! Been waiting for this day to say RTBC+1 for quite some time.
I am using patch #510 from this issue
and
patch #6 in #2339315: Source language prepopulated values should be also included in $form_state['field']
as described in comment#512
I retested the use cases, looks like the real key here is the patch to entity_translation , this should also be getting our attention.
Comment #514
joseph.olstadsee related issue.
Great work once again everyone!
Just to clarify, our unlimited field collections are now properly translating using entity_translation.
Comment #515
mrchristophy CreditAttribution: mrchristophy commentedThis is great news! Just to be clear, which versions of Field Collection and Entity Translation should we be using for these patches?
Comment #516
Kristen PolWe are using versions:
and patches:
Cheers!
Comment #517
loopduplicate@Kristen you wrote, "Field Collection - 7.x-1.0-beta10+1-dev (afraid to update to beta11 right this second :)"
Actually, 7.x-1.0-beta10+1-dev is the same as 7.x-1.0-beta11... we aren't afraid :) http://cgit.drupalcode.org/field_collection
Comment #518
wroxbox CreditAttribution: wroxbox commentedHere is long tests with screenshots from both admin and public site + some database tables:
Our setup:
core: 7.42
Nodetype: Service_card (Revisions enabled, entity translation)
field_short_description (Enabled field translation)
field_deployment (Field collection with field translation enabled, unlimited values)
- field_short_description (enabled field translation, same field as in node)
This works:
This does not:
What happens. The original english value inside field collection is visible in form as the translated too, but their revisions are mixed as the original entity translation data:
Node field & Entity Translation + Field collection field & Entity Translation
Above is the data from the first saving
-----------------
Add translation
-----------------
Now the entity translation table has two same language items, as the original (38776) should be en.
Also the field inside FC got third line in database mixing revision and language.
By removing Revisions from node the setup works perfect.
https://dl.dropboxusercontent.com/u/775110/ss/settings-for-field-collect...
https://dl.dropboxusercontent.com/u/775110/ss/1-translatable-field.jpg
https://dl.dropboxusercontent.com/u/775110/ss/2.1-field-collection-item.jpg
https://dl.dropboxusercontent.com/u/775110/ss/2.2-field-short-descriptio...
https://dl.dropboxusercontent.com/u/775110/ss/3-translated-node-field-co...
https://dl.dropboxusercontent.com/u/775110/ss/3.1-original-field-collect...
https://dl.dropboxusercontent.com/u/775110/ss/3.2-modify-field-collectio...
https://dl.dropboxusercontent.com/u/775110/ss/3.3-field-collection-trans...
https://dl.dropboxusercontent.com/u/775110/ss/3.4-field-collection-field...
https://dl.dropboxusercontent.com/u/775110/ss/3.5-field-items-inside-fc-...
Comment #519
joseph.olstadHi wroxbox, I tested my use case with revisions by enabling revisions (basic page with unlimited field collection of float with description) and everything seems to work on my end.
I'm using:
entity_translation:
version 7.x-1.0-beta4
only one patch for entity_translation:
entity_translation-prepopulate-form-state-2339315-6.patch
#2339315: Source language prepopulated values should be also included in $form_state['field']
field_collections
version: 7.x dev hash number ec024e5cfb5
from Thu Oct 22 16:51:03 2015
with patch number 510 from this issue
I suspect there to be a problem with your heavily patched entity_translation module suggest re-testing your use case with a new copy of entity_translation 7.x-1.0-beta4 with the patch from #2339315: Source language prepopulated values should be also included in $form_state['field'] , I'm successfully using patch 6.
The aforementioned config with revisions enabled OR disabled is working for me.
Comment #520
wroxbox CreditAttribution: wroxbox commentedHi Joseph
I tested your setup and removed the heavily patched entity translation. No success. Our patches were fixing Entity translation over taxonomy terms and also using latest dev of ET.
Created completely new content type with only one field collection (unlimited, field translation enabled) with one field inside (translatable) and the same issue remains.
Comment #521
joseph.olstadwroxbox, I forgot to mention, I'm using D7 core 7.39, not sure if that makes a difference.
and I'm not using workbench in my test environment. its pretty barebones aside from i18n and the entity_translation.
perhaps my use case is different enough than yours but I'm hoping maybe we can get some more people testing and sharing their test results as I'm very pleased with the progress.
idflood - can you retest your use case with the new patch for entity_translation and field_collection? this'd help a lot. anyone else, please?
Comment #522
Stevel CreditAttribution: Stevel commentedI've tested the patches (from #1344672-510: Field Collection: Field translation (entity_translation) support. and ET #2339315-9: Source language prepopulated values should be also included in $form_state['field']) on Drupal 7.43, translatable node, untranslatable field collection containing some translatable fields.
Everything seems to work as expected, but some tests are still failing in our deployment workflow (same as in #1344672-506: Field Collection: Field translation (entity_translation) support.).
Comment #523
achapI have tested the patch at #510 along with the related patch mentioned in that comment from entity_translation #6. It is working for me. Drupal core 7.41, Field collection 7.x-1.0-beta11 and entity_translation 7.x-1.0-beta4. I set the field collection itself (rather than the field collections fields) to translatable.
Comment #524
badrange CreditAttribution: badrange at Wunder commented@joseph.olstad, @wroxbox - I may be clutching for straws here, but could the differences you experience be caused by having different settings for Field collections under "Translatable entity type" at
/admin/config/regional/entity_translation
?Comment #525
wroxbox CreditAttribution: wroxbox commentedComment #526
iamfredrik CreditAttribution: iamfredrik commentedI get this error when running updb after applying the latest patch:
"Unable to save a field collection item without a valid reference to a host entity. "
How to fix this?
Comment #527
dewalt CreditAttribution: dewalt commentedThere is an issue with field validation - invalid values reported by hook_field_validate() causes 500 error on site. The issue exists for patches from #248 to #510. Other patches weren't checked.
Behaviour to reproduce:
1. Create node type, configure entity_translation handler.
2. Add untranslatable entity_collection field.
3. Configure entity_translation handler for field_collection entity.
4. Add translatable field to field collection. (I used link field)
Steps to reproduce
1. Go to node creation form (/node/add/)
2. Fill invalid URL in "URL" input of link field.
3. Submit form.
Expected: form is shown with validation errors
Actual: 500 error page is shown
Propose to fix
The error takes place because language of the field in field collection item entity is changed by EntityTranslationHandler::entityFormLanguageWidgetSubmit() before field is validated. And field validation expects, that validating field value has the same language, as used to built form element.
See screenshots.
Mooving field_attach_form_validate() before entity is processed by translation handler fixes the problem.
I created patch with the fix, based on #510 one.
Comment #528
loopduplicateHere's an interdiff between 510 and 527. I didn't have time to review 527 but I figured that an interdiff would help.
Comment #529
loopduplicateWell, crap. The interdiff shows that the patch in #510 no longer applies right. The #510 patch used hook_update_N, 7007 but the latest dev version of field_collection added 7007 as well.
Comment #530
loopduplicateHere's an updated patch for 510. This doesn't include the change made in #527. I'm uploading two interdiffs: 510 vs 530 and 510 vs 527.
The patch in #527 seems to mess up field_collection.install by adding two 7007 updates.
*edit* Please do not use the patch in this comment. Use one of the patches in #531. If you just want a reroll of what was in #510, use the patch "field_collection-entity_translation_support-1344672-531-without-527.patch". If you want to incorporate the changes that were suggested in #527, use "field_collection-entity_translation_support-1344672-531-with-527.patch" . -loop
Comment #531
loopduplicateugh. The patch in #530 is missing includes/translation.handler.field_collection_item.inc . Sorry about that. Anyway, here's two updated patches. Each patch addresses the hook_update_N issue. One of the patches incorporates what was done in #527 and the other is basically a reroll of #510.
Comment #532
loopduplicateComment #533
wizonesolutionsAre the issues in the issue summary still a problem? I would like to update the issue summary to include some steps to reproduce/review or a description of what the patches to be reviewed add, if anything needs to be configured, etc....but I lack information. @loopduplicate?
Comment #534
loopduplicateHi @wizonesolutions,
I'll answer your questions one at a time.
"Are the issues in the issue summary still a problem?"
The summary is very out of date. For example, it says the patch to use is from #437 but that's not true anymore. The remaining tasks section says, "Update hook may delete existing data". I'm not sure if update hooks delete existing data because I originally tested on a new site and never had the need to run updates.
The best help I can give right now is to give you the 'recipe' that got all this working for my particular use case. There still needs to be tests written. Once the tests are written, it should be clear what is still broken and what works.
Recipe:
Use this patch from #531:
field_collection-entity_translation_support-1344672-531-without-527.patch
Use this patch from https://www.drupal.org/node/2339315#comment-10884422
entity_translation-prepopulate-form-state-2339315-8.patch
Set up your fields like this:
* A translatable node
* A translatable field collection in the node
* A non-translatable field collection in the field collection
None of the fields in the field collections need to be set to translatable.
Regards,
loopduplicate
Comment #535
joseph.olstadHi @loopduplicate , nice work, just ran the built-in simpletests for "field" using the following scenario and got these detailed results ;
Scenario:
enable the "simpletest" module
go to: admin/config/development/testing
Select "Field types" from the available list of tests
the check "field collection entity translation"
then click on "Run Tests"
Configuration prior to running tests:
Latest core 7.43
entity_translation module with your (loopduplicate patch 8 of issue #2339315: Source language prepopulated values should be also included in $form_state['field']):
Latest dev of field_collections 7.x-1.x:
With patch 531-without-527 and the latest dev of field_collections
with patch 531-with-527 and the latest dev of field_collections
Results:
everything passes, except these two:
field_collection.test line number 1195
"Value NULL is equal to value 'Translatable DE Mod'."
field_collection.test line number 982
"The field collection item has been removed from the database."
I checked and this is the same simpletest results that patch 510 gave with the older dev.
Summary
It looks like your patches 531 are an improvement having resolved your issue and have not caused any regression. There is still the outstanding failures on the simpletest that existed previously on the previous patches, I haven't looked closely to see what is causing this, if the simpletest is needing an update or if its actually a problem that we need to solve. I'm hoping that the simpletest results will help us finalize this patch and commit it.
Thanks
Comment #536
loopduplicateThanks Joseph!
Comment #537
gnucifer CreditAttribution: gnucifer commentedUsing the patch in #534 (field_collection-entity_translation_support-1344672-531-without-527.patch), I still got a crash when using nested field collections if the parent field collection has more than one item. After an especially painful debugging session I tracked down this but to Entity translation module and now feel an urgent need to sooth my poor brain with some alcohol. I will create and issue (with the patch) in the Field Collection issue queue and link to it here.
EDIT: Patch can be found here: https://www.drupal.org/node/2715091See this issue instead: https://www.drupal.org/node/2339315
Comment #538
gnucifer CreditAttribution: gnucifer commentedHere is a patch based on field_collection-entity_translation_support-1344672-531-with-527.patch integrating the field state alter hook added in entity_translation-prepopulate-form-state-2339315-14.patch (https://www.drupal.org/node/2339315#comment-11133945)
Comment #539
loopduplicateHi gnucifer,
I'm a little confused by your comments. In #534 I said that you need the patch from 531 and you need the entity translation patch. But then in your #537 comment, you wrote "After a very long and especially painful debugging session I tracked down this but to Entity translation module". I mean, it sounds like you didn't apply the entity translation patch. In fact, in that same comment #537 you link to the entity translation issue with the patch I said was needed. (https://www.drupal.org/node/2339315)
I'm probably being stupid, but can you explain why using your new patches (the one here and the one on the entity translation issue) is better than using the patch from #531 here in combination with the patch from #9 on the ET issue, as outlined in #534?
Regards,
loop
Comment #540
loopduplicateOK, I was being stupid. I looked more carefully at the other issue. Thanks gnucifer :)
Comment #541
gnucifer CreditAttribution: gnucifer commented@loopduplicate Yes, the size of this issue got the better of me and completely missed that there was a patch for entity translation fixing the problem with nested field collections. I unnecessarily created a duplicate patch with an alternative solution. I have now abandoned those changes, and instead made some adjustments to the original patch.
Comment #542
loopduplicateOK, I'll try to clarify:
The current best solution seems to be to use your two latest patches:
* From this issue, #538:
** https://www.drupal.org/files/issues/field_collection-entity_translation_support-1344672-531-with-527-538_0.patch
* From the Entity Translation issue, #14
* https://www.drupal.org/files/issues/entity_translation-prepopulate-form-state-2339315-14.patch
The above solution hasn't been tested by many people yet but #535 has instructions for running some automated tests, when someone has time.
Regards,
loopduplicate
Comment #543
jmuzz CreditAttribution: jmuzz commentedSorry about the test settings guys. Tests should get run for 7.x now.
Comment #544
joseph.olstadPlach recently published "Entity Translation" 7.x-1.0-beta5 which includes the related patch previously required for this issue.
What is now needed:
I'm thinking that we're very close to being able to commit. If I was maintainer of this project I'd commit the best available patch and let people open new tickets for the "edge" cases that may be remaining.
Comment #545
gnucifer CreditAttribution: gnucifer commented@joseph.olstad A small correction, #538 contains the alter_hook introduced in the latest version of entity transalation, #543 is an older patch on which #538 is based, so perhaps #538 should be considered the best candidate.
Comment #546
sinasalek CreditAttribution: sinasalek at Practicalidea commented@joseph.olstad good point, it does not have to be released right away. but when it's committed more non technical people can also easily test it. It's a monster patch, difficult to review, difficult to keep it up to date with dev and difficult to manage. good job everyone so far
Comment #547
james.williams CreditAttribution: james.williams at ComputerMinds commentedLet's do it! Tests do now pass, and there have now been many eyes on the work so far. So I'm marking this as RTBC *for the patch in comment #538. Yes, there's outstanding issues, but they can be covered in follow-up issues rather than trying to continue working on this increasingly-monolithic patch/issue. Then hopefully each outstanding issue can be dealt with in smaller/easier issues. The patch from #538 definitely covers many use cases and does work for them as far as has been seen so far, so getting this committed would be a great step to completing full entity translation support as it will then cover that for many (most?) users.
Of course someone could argue me down and change the ticket status back, in which case, fair enough, I'll accept that! :-)
Comment #550
jmuzz CreditAttribution: jmuzz commentedI took the with-527 version and I fixed a couple of small issues:
The big data deletion issue still remains. I'll give some more specific steps about how to reproduce it.
Get a new drupal core. Create a dir sites/all/modules/contrib , all the required modules will go inside it. Get the following modules and put them in contrib. I don't believe the version matters:
Get the latest dev version of the following modules:
Get the database from #332 and don't worry about the instructions there or the smartling modules they are not needed.
Import that database and set up this drupal install to use it. The site should work at this point. See the nodes with field collections. They have "collection3" fields with filled in text field values in field "text3".
Reset the admin password (for example
drush upwd admin --password="admin"
) and see that the node edit forms are functional.Apply the entity translation patch.
Run /update.php .
See an error message
Failed: Exception: Unable to save a field collection item without a valid reference to a host entity. in FieldCollectionItemEntity->save() (line 431 of /home/jmuzz/devel/local.smartling.com/sites/all/modules/contrib/field_collection/field_collection.entity.inc).
Try to edit the nodes with the field collections. See that the data is no longer in the forms.
Clear the cache.
Look at the nodes with field collections and see that the lines under "collection3" fields are blank.
Check out the database and see that the data is gone, for example:
Comment #551
stefan.r CreditAttribution: stefan.r commentedNeeds work or needs review?
Comment #552
jmuzz CreditAttribution: jmuzz commentedAs long as it's going to delete data it needs work.
Until that is addressed the review is: "Needs to stop deleting data"
Comment #553
loopduplicateDoes anyone feel comfortable updating the description in this issue? It's pretty outdated.
Regards,
Jeff
Comment #554
joseph.olstadjmuzz, I have not found any data integrity problems in my tests.
I acknowledge your concerns however this module is still flagged as "beta" , my take on it is the "beta" code is producing corrupted nested field collections, this patch we're working on as far as I see creates valid nested field collections since patch 510 .
For the sake of progress I propose a few options:
1) Provide a 7.x-2.x branch for entity translation support using a fork of the 7.x-1.x branch patched with the latest patch of this issue, then once a 7.x-2.x branch is created we can open issues for dealing with handling corrupted beta 1.x nested field collections in a more graceful way without deleting them.
or
2) commit this patch as is on the dev branch, open a new issue for the delete and delay tagging a beta 5 or a 1.0 release
Above you've provided a database , however that database was created using beta code prior to the patch when nested field collections were not working correctly previously.
Seems like we've got a dozen eggs, some were broken before, should we try to put the eggs back together again or eat the scrambled eggs and get some chickens to lay some new eggs?
Comment #555
jmuzz CreditAttribution: jmuzz commented@joseph.olstad I want this to be committed too, and I like the thought that it might be a problem with the database and not the patch. I don't recall seeing any such corruptions though when I was working with that data and trying to solve the problem. Could you be more specific about the corruption, link to "the patch when nested field collections were not working correctly," or provide any other evidence that that may be what's happening?
I did use a #510+ version of this patch.
I also tried updating the smartling database without this ET patch and it didn't delete anything. The data is deleted during the 7008 update added in this patch.
Comment #556
joseph.olstad***EDIT***
see comment #558
jmuzz, this issue woke me up at 4am , it became apparent that I had not actually run a updatedb after having applied the patch. In my test cases I was working on new data that I was adding in. Could it be that update_7008 is no longer needed? What would happen if we just removed the update_7008 from these patches?***EDIT*** see comment #558
Comment #557
maxplus CreditAttribution: maxplus commentedHi Thanks,
I started testing patch #550 in combination of latest dev of Entity Translation on a production site.
Comment #558
gnucifer CreditAttribution: gnucifer commented@jmuzz @maxplus You are using an older patch which does not implement the new hook_entity_translation_source_field_state_alter introduced in the new version of entity translation. Try the one in #538 instead.
Comment #559
letrotteur CreditAttribution: letrotteur commentedCan't apply #538 cleanly to latest dev.
Comment #560
jmuzz CreditAttribution: jmuzz commentedI re-rolled 538, got the latest repository version of entity_translation, and tried running the update on the smartling database. The data is still being deleted and in addition the attached error messages showed after the update.
Was the addition of the hook supposed to address the data deletion?
Comment #561
jmuzz CreditAttribution: jmuzz commentedI dug into the smartling example some more and found that it was expecting a missing entity controller. I think the smartling module suite is supposed to provide it but when I download that the site no longer functions, so I'll agree with @joseph.olstad that it isn't such a great example afterall.
Comment #562
jmuzz CreditAttribution: jmuzz commentedComment #564
jmuzz CreditAttribution: jmuzz commentedIt was already marked RTBC in #547 based on a lot of comments and testing.
Thanks everybody for all the time put into this and for being persistent. It wasn't easy but I'd call this a success.
If there are any further problems related to entity translation please create a new issue and do not reopen this one (ever).
Comment #565
sinasalek CreditAttribution: sinasalek at Practicalidea commentedAfter more than 4 years, The impossible has just happened. Thanks everyone for all the hard work
Comment #566
plachOh, wow, this is disappointing, I was hoping we'd reach comment 600 ;)
Jokes aside, thank you all for your tireless efforts, I'd call this a huge success!
Comment #567
joseph.olstadThanks everyone! This was a big one!
Comment #568
jramby CreditAttribution: jramby commentedWoooow guys, it has been a long one!!! you're all awesome!! Thanks to all!!
Comment #569
giupenni CreditAttribution: giupenni commentedWoooow! Thank you everyone, you're all awesome!!!
Comment #570
jmuzz CreditAttribution: jmuzz commentedFollow up issue about tests now failing in HEAD.
Is is just me, or does it look like the tests passed when they were posted in this issue?
I'm trying to figure out what is going on. Are we supposed to have to click on the lines that say the tests passed to find out whether or not they passed?
Comment #573
sinasalek CreditAttribution: sinasalek at Practicalidea commentedJust to check @jmuzz comment
Comment #574
edi44 CreditAttribution: edi44 commentedHello, I'm not able to get field_collection working with entity_translation 7.x-1.0-beta5... using latest dev not working... try to patch module run in erros...
How can i get this to work? Which version should i use? Which patch?
Comment #575
james.williams CreditAttribution: james.williams at ComputerMinds commentedHi @edi44 - entity_translation 7.x-1.0-beta5 and the latest 7.x-1.x-dev should be compatible and already contains the final work from this ticket, so no patch from this ticket should be necessary.
As this is an old closed issue, please could you open a new support request, detailing your specific problems/errors if you are getting them even without patches? Thanks!
Comment #576
mastoll CreditAttribution: mastoll as a volunteer commentedThis is the latest translation issue that I can find. Is the latest patch from this ticket working?
When updating FC from 1.0-beta 5 to the June-23-16 dev version.
Running PHP Update:
Pending update:
field_collection module
7008 - Update fields in field collections already set to use Entity Translation.
The error reads:
Update #7008
Failed: Exception: Unable to save a field collection item without a valid reference to a host entity. in FieldCollectionItemEntity->save() (line 442 of .....\field_collection\field_collection.entity.inc).
Comment #577
loopduplicateHi mastoll,
I'm going to write something similar to what was in #575.
You wrote, "This is the latest translation issue that I can find. Is the latest patch from this ticket working?"
The code from this ticket has been committed already. This mean, among other things, that any patch from this issue will not apply to the latest dev version. Perhaps what you should do is create a new issue, since you can't find an existing open one that is relevant. In the new issue describe the problem you are having. I would mark your new issue as related to this one.
Regards,
loop
Comment #578
mastoll CreditAttribution: mastoll as a volunteer commentedI know the latest patch from this issue has been committed. I'm wondering if it's working. More specifically, I'm wondering if update #7008 is the commit of the patch from this issue. See, the update is failing and I'm trying to figure out which issue the update is connected to so that I CAN relate whatever post to the correct place.
Comment #579
james.williams CreditAttribution: james.williams at ComputerMinds commentedHi @mastoll -- yes, update 7008 was indeed added by the work in this ticket (see http://cgit.drupalcode.org/field_collection/commit/?id=c4d64f9d987eb9bde...), so yes, please create a new ticket outlining the problem, and relate that ticket back to this one.
This particular ticket has been going on for a very long time and so we were all just happy to move on from it. If there's a problem with this work, of course that needs resolving though, so thanks for finding it! Let's just continue in a new ticket to give a fresh clean start for the fix, rather than years of history and 500+ comments that we have here :-)
Comment #580
gnucifer CreditAttribution: gnucifer commented@mastoll It's working (at least for me, so far :)). The error you got is because you have database-corruption for your field collections, with orphaned field-collections missing a host entity. This might still be field-collection's "fault" though, I have experienced the same thing. It can be solved by writing a clean-up script, for example:
drush php-script delete-orphaned-field-collections.php
. Basically write an entityFieldQuery loading all field collections, check if ->hostEntity() returns false, and delete those field collection items. You might want to check the data first so you are not deleting critical data, and salvage it in some manner.Comment #581
lexa.mihu CreditAttribution: lexa.mihu commentedSame problem as #576
Comment #582
james.williams CreditAttribution: james.williams at ComputerMinds commentedFollow-up ticket created: #2759157: Orphaned field collections break update 7008. Let's move discussion around this problem with update 7008 to that ticket and leave this original, closed, ticket (and the 200+ people being notified by updates to it!) to rest in peace :-)
Comment #583
dianikol CreditAttribution: dianikol commentedI'm a little confused here. Which patch I need to apply??
Thanks
Comment #584
james.williams CreditAttribution: james.williams at ComputerMinds commented@dianikol - the work done in this ticket is already part of the latest dev release (7.x-1.x-dev), but is not yet included in an official 'stable' release.
That said, you may also need the spin-off patch in #2759157: Orphaned field collections break update 7008, if you experience problems on running updates on that release.
Comment #585
dianikol CreditAttribution: dianikol commented@james.williams - All good. All my content on my FC is there
My setup is I have translatable the host FC field on the node and non translatable the FC field itself. In case someone miss this setting we need to make Field collection translatable on the Entity translation configuration.
James do you think I should apply the patch you mention anyway?
Thank you everyone, you just add a lot more value to the Drupal
Comment #586
james.williams CreditAttribution: james.williams at ComputerMinds commentedNo, you will be fine without the other patch. The other patch is just used if you had previously-corrupted/invalid data that translation would now be incompatible with. If you didn't get warnings about that, you don't have bad data in that way to be concerned about*!
*as far as we know ;-)
Comment #587
titouilleHi,
Has anyone tried to translate field collections embed in paragraphs ?
I created a field collection with some fields in a paragraph bundle. The paragraph bundle is added to the basic page node bundle.
I enabled ET for basic page, paragraph bundle and field collection.
Basic pages has translations on field level.
Paragraph bundle is not checked as translatable in field definition (from basic page), but has some translatable fields.
Field collection is not checked as translatable in field definition (from paragraph bundle) but has some translatable fields.
When I create a basic page in english, I add a new paragraph with the field collection fields embedded. I fill some fields and save the content. All is ok
When I translate the basic page in french, paragraph display the english values in form, field collection too.
I change the values of paragraph translatable fields and field collection translatable fields and save the form.
Values are saved successfully.
But when I return on the original (english) content, Field collection display me a "English translation unavailable for Elements 1." message.
The paragraph is translated successfully, but field collection erase the original content with the french content.
In database, translatable fields hosted by field collection are in the two languages (two entries for each field) but field collection itself indicate that the original language is french and has only french translation, no english.
It seems that the process erase the language informations by the latest used language in form submit. If I edit and save the original (english) content, this time the field collection indicate original language as english and only english key is found in the "translations->data" key.
When I go to edit mode in french or english, I can see the field collection sub-fields translated correctly, so it can retrieve correct informations for the sub-fields, but erase the "translations" informations each time I save a basic page.
I'm using
field_collection 7.x-1.0-beta11+11-dev
entity_translation 7.x-1.0-beta5
paragraphs 7.x-1.0-rc4+5-dev patched with https://www.drupal.org/node/2452675#comment-11418169
If anyone has an idea...
Thanks in advance.
Comment #588
dianikol CreditAttribution: dianikol commentedHey, Is the final patch commited to the last update beta version (2016-Nov-17) or should i apply it ?
Thanks
Comment #589
hgoto CreditAttribution: hgoto as a volunteer and at Studio Umi commented@dianikol, I believe the patch is included in the version 7.x-1.0-beta12. You can check it in the following pages :)
Comment #590
dianikol CreditAttribution: dianikol commentedCool Thanks
Comment #591
blacklabel_tom CreditAttribution: blacklabel_tom at Edo commentedHi,
I'm working on a site that DOES NOT have entity_translation installed and have updated to the latest version of field_collection (7.x-1.0-beta12) and I'm getting the following error when trying to run any drush command:
Looking through the modules I can see that Content translation (translation) is enabled, which could be conflicting.
Will investigate at my end to see if I can figure out if this is a site issue or a module issue.
Cheers
Tom
Comment #592
DamienMcKenna@blacklabel_tom: Please open a new issue for this bug.
Comment #593
Sneakyvv CreditAttribution: Sneakyvv at Calibrate for Government of Flanders commentedMight be barging in here unappropriately, but can anyone tell me why in commit c4d64f9d these lines were added in field_collection_field_widget_embed_validate() (line 1587 in field_collection.module) ?
In my use case, using paragraphs and paragraph_panes, the field collection item's item_id is not set since it is new (and attached to a non-saved paragraph item). To be even more specific, the paragraph item is never going to be saved at all, since that's the way paragraph panes is set up.
Without, for now, going deeper into detail, these lines break my module and I suppose my question is whether these lines are really necessary, since I seem to be able to create FC items without them. Both attached to an actual host entity and not.
I don't have entity translation enabled and I understand that's what this issue is about (I didn't read all 500+ comments) and thus these lines must have been added for that purpose, which my case might not be exposed to (i.e. therefore removing the lines is only not a problem for me, but it is in general).
Either way, I assume that there's some other code which, if the value key is not set (as it is in my case for a new FC item), will create a new entry in the database and checks the value key for that purpose. However, if that is the case, i.e. that's the only purpose of setting that value key, then I guess there won't be any harm done in putting an extra check around the lines above, which prevent setting the value key if there is no FC item_id, assuming of course that there's a empty() check in "that other code", and no isset() check... Or do you guys have a reason why that should not be done?
Comment #594
juampynr CreditAttribution: juampynr at Lullabot for NBCUniversal commented@blacklabel_tom I experienced the same issue that you reported at #591 and created a new issue with a workaround at https://www.drupal.org/project/field_collection/issues/3117095.