When trying to use paragraphs in conjunction with entity field translation, i get this error when saving the translated node.

Notice: Undefined index: entity in paragraphs_field_widget_embed_validate() (line 1375 of /Users/home/me/SERVER/sites/all/modules/paragraphs/paragraphs.module).
EntityMalformedException: Missing bundle property on entity of type paragraphs_item. in entity_extract_ids() (line 7693 of /Users/home/me/SERVER/includes/common.inc).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jeroen.b’s picture

Thanks! Can you test alpha7?

petergus’s picture

Thanks!
That seems to mostly work, yet still buggy.

So after node is created in english, i go to translate, and as i would like, the default content is there on the translation edit page. If i do not change the values, then as expected it shows the default english content in the translated page. All fine till now.

However, i go to edit the newly created/translated page, and the values are gone! infact, i have to select and add a Paragraph in as if it never existed.

Is this reproducible? I dont know if its me, because i also notice that the menu is renaming itself to the default english during this time also.

jeroen.b’s picture

This is kinda hard to fix. As paragraphs field only store a reference to the entity_id. Cloning the content of this field will mess things up (two nodes referencing to the same entity, editing it in 1 place will also edit it on the other.).

I'm gonna check how other modules like field_collection do this, though I suppose they don't handle this at all.

I don't use field translation, so my priority for this isn't very high, sorry.

cyxair’s picture

Hi,
I'm following Paragraphs closely as I've dreamt of this module for years, struggling with field_collection for now.

Here's what I encountered when testing node translation (i18n module) on a fresh install :
1/ create a node containing a Paragraph field, let say in "FR" language.
2/ add some paragraphs
3/ save the node
4/ click on "translate" : as expected, a populated node edition form is displayed
5/ modify paragraphs content
6/ save translation : the modification are made on both node's paragraph fields

I guess that paragraph entities are not duplicated when adding a translation.
- Shouldn't the paragraph entities be duplicated ? (to be able to translate them, and avoid deletion when removing from one translation)
- Maybe this behavior could follow the Synchronize translation setting on the content type (setting provided by enabling i18n_sync for each field) ?

derhasi’s picture

The problem with entity translation is that it automatically copies field forms form the default language to the current language (@see entity_translation_prepare_element()) and does not care about the form state at the moment. That is difficult to catch in the widget. The team from "field collection" are struggling with proper entity_translation support too (#1344672: Field Collection: Field translation (entity_translation) support.).

I could fix the problems with entity translation by going without the "default from source language" feature. This is achieved by "disabling" entity_translation_prepare_element() for all paragraphs fields. This way we simply have an empty paragraph field, when translating. Sure, that has some downsides in the experience, but at least we can use paragraphs.

I attached a patch that implements the changes.

  • Commit 01a120e on 7.x-1.x by jeroen.b:
    Commit patch 2152931-5 from #2152931 by derhasi
    
jeroen.b’s picture

Patch by @derhasi is committed.
Best would be to just clone the paragraph item, is there any module that already clones the entity for entity translation? (inline_entity_form? field_collection?)

jeroen.b’s picture

Status: Needs review » Needs work
derhasi’s picture

The problem with "simply copying" is, that we cannot (or I currently cannot see a way to) distinguish, whether the translation is new or the translation already existed and the field was left empty on purpose. If that cannot be solved automatically, maybe we could add a button for "copy from source", when ET is enabled.

Nicolas Bouteille’s picture

Hi,

We should be able to share some Paragraph items like images or slideshows between translations the same way we can have ET fields shared across translations.

That way if we update an image it gets synced on all languages.

How do we do that? Well I believe this is where "Reusing items" feature https://drupal.org/node/2250393 becomes not only handy but simply a MUST HAVE...

IMHO this is a very neat way to allow end-users to have Paragraph items synced across translations.

This is already possible with Inline Entity Form.

Now, I also agree it would be good to have all Paragraph items from the source version automatically cloned into the translated version to avoid going back and forth between source and translation when actually translating items...

But then, how can you reuse some existing items if they just got all cloned and unsynced from source version?

Well I see two options:

1/ ideally, when we first add the new translation, a screen makes us choose which fields we want to clone and thus unsync, and which on the contrary we want to be synced / reused / shared with the source.

Now if this is too difficult, here's option 2:
The decision could be made per bundle. So for example you would tell Drupal that all items of the "Image (shared)" bundles should not be cloned but synced between translations.

Problem with option 2) is you would have to create two "Image" bundles if you think there could be a risk that some end-users want to have specific image per translation.

Plus, the fact that things happen automatically in the background without asking the end-user what he/she wants could make him/her not understand what's going on.

That's why 1) is optimal IMHO.

Now, for solution 1) to be ergonomics, if we want to easily select items, we would actually need to display them all collapsed with administrative title only... which means all items should have an administrative title... which is another feature request I made that you guys think is too complex for the end-user... https://drupal.org/node/2138767#comment-8690345

Hope you guys will take some time to rethink all this... I believe Inline Entity Form has been created a long time ago, it hasn't been that way from the first day... I remember getting redirected to another page to be able to edit an entity at the early days... I believe its maintainers have already spent hours figuring out how to do those things the best way possible and we should follow their way... at least for the common part.

You actually know my point of view on that matter is... I think Paragraphs shouldn't have actually duplicated Entity Reference and Inline Entity Form but used them as dependencies instead and built on top of that. Did not get any feedback from you on that though...

Nicolas Bouteille’s picture

I opened another issue, in Nested Box this time, where I first explained the same thoughts but clearer and deeper, and then pushed the reasoning it a little further.
https://drupal.org/node/2258889

jeroen.b’s picture

@Nicolas Bouteille, Please keep the discussion about reusing items in the issue you created about it: #2250393.
This issue is about making Paragraphs compatible with Entity Translation.

The other ideas you have rather seems to be something you want in the Entity Translation module, not in Paragraphs.

Also, I think Inline Entity Form has the same issue we had, it copies the Entity ID value to the translation, which makes it reference the same entity, so when you edit it on the translation, it will also be edited on the original.
For that reason we disable the copy, until we have a good solution to actually create a new paragraph entity and copy the actual field values. (also, what happens if you have a field collection in a paragraph bundle, then you have the same issue, even if you fix it on the first level. Again, this might be something to fix in Entity Translation?).

Also, using Entity Reference or Inline Entity Form as a dependency was not a viable option, as the entity is different and the db schema is different too.

Nicolas Bouteille’s picture

Ok but before making Paragraphs compatible with Entity Translation, maybe first you wanna decide what to expect in the end no?
I only mentioned the reuse of Paragraph items because I believe it becomes useful for translation possibilities.
Maybe not everything can be done from the Paragraphs module but in ET directly instead. But first priority I believe is decide what we want to be able to do. Then we can open issues in adequate module.

derhasi’s picture

Conceptually, reusing paragraph items, would add a lot more to look at when dealing with CRUD of that paragraph. The complexity of CRUD and translations will increase drastically, when we try to implement that.

Translation itself is a real complex topic, as we have to deal with multiple scenarios. Creating a copy paragraph and (initially) syncing the fields might be a good solution, but is only for one use case. There could also be a scenario, where the paragraphs shall be the same in every language, but the fields shall be translatable.

I might investigate that whole topic later again, when there is some spare time.

jeroen.b’s picture

Maybe this should even be fixed in Field? At least in Entity Translation or Entity.
Developers should be able to mark their field as a "referencing field" (where the value is nothing more than some ID pointing to some Entity).

So when I change my hook_field_info to include 'reference_field' => TRUE, and the node is translated, it would fetch the underlying entity, copy the fields of that one and put it in a new Paragraphs Item (or any other reference field) Entity.

This would fix it for any field, and on any level of referencing (think of node->paragraphs->inline entity form).
Of course this would require some work from the developers of other modules, but it's the easiest fix for everyone.

Maybe we should take this discussion elsewhere? Maybe to Entity Translation?

tocab’s picture

I got the same error when trying to remove a paragraph item from the node editing page.

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7729 of /var/www/kering-foundation/includes/common.inc).

I don't got this error when clicking on the "Remove" button, but when clicking on the "Confim Deletion" button or when saving the node (cf screenshots).

I got the entity translation module enabled and my field is a mlti-valued paragraph field.

tocab’s picture

In fact my problem is solved with the dev version of entity_translation (before it was the la tatest stable version : 1.0-beta3).

jeroen.b’s picture

Hmm really? That would be great! Will test this later.

jeroen.b’s picture

Status: Needs work » Closed (duplicate)

A new attempt is ongoing in https://www.drupal.org/node/2331273 so I'll close this one.

criz’s picture

Can confirm that this issue is solved by using latest entity_translation dev version.

gagarine’s picture

@criz can you check if this is also fixed? #2388185: Fully support Entity Translation

seanB’s picture

In the field_collection module there was a similar problem, they fixed it without having to rely on the replicate module:
http://cgit.drupalcode.org/field_collection/commit/?id=1972527

I don't have time to test this now, but it might be worth checking if the paragraphs module can solve it in the same way.