Closed (outdated)
Project:
Paragraphs
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
9 May 2014 at 13:03 UTC
Updated:
13 Nov 2019 at 21:50 UTC
Jump to comment: Most recent
In paragraphs_field_widget_form_build() field_attach_form() is called directly with $element. But this may lead to unforeseen behaviour. A concrete problem is, that there is an $element['#entity'] attached, that is the host entity of the given field in that moment. When field_attach_form() is called, the Drupal Field API replaces that with the pargraphs entity in some cases: @see field_default_form().
I suggest that the attached form, should be placed in $element['subform']. I'm currently investigating that stuff, as I think that provides some problems when storing the delta values or weight.
Comments
Comment #1
jeroen.b commentedIs this actually giving issues?
Do you have any steps to reproduce this or do you just suspect a problem with it?
Comment #2
duaelfrI have an issue for which I am not able to find the source and that could be caused by this kind of things.
I deployed a content type with a few paragraphs on my stage server then created some example nodes using these paragprahs.
My users started to edit the nodes and play with them.
Later, I deployed more paragraphs styles and let my users continue playing with their content.
A few days later, they fill me an issue explaining that image upload is not working anymore on their nodes.
Digging a bit, I find that somehow, a few paragraphs has been duplicated in their host entity. They are nested paragraphs so I can see in the database two paragraphs containing the same sub-paragraphs.
Here is a "schema" to explain a bit more:
- Content type: page
- Paragraph field: field_paragraphs (unlimited, can contain 'columns' paragraphs)
- Paragraph type: columns
- Paragraph field: field_columns (unlimited, can contain 'column_item' paragraphs)
- Paragraph type: column_item
- Text field: field_title
- Image field: field_image
At start:
I had a 'page' node (nid=1) containing one column (item_id=1).
I had a 'columns' paragraph (item_id=1) containing two column_items (item_id=2,3)
A few days ago:
I have a 'page' node (nid=1) containing two columns (item_id=1,4).
I have a 'columns' paragraph (item_id=1) containing two column_items (item_id=2,3)
I have an other 'columns' paragraph (item_id=4) containing two column_items (item_id=2,3)
I have no idea about what happened and I don't know is it is related but I think it could be.
I hope my case will give you a clue on this.
Comment #3
derhasi commentedThat is the behaviour I started researching the code for. In code there is not obviously a way to figure that out, because Form API and Field API do a lot of work in obfuscating the widget behaviour. I have to take a deeper look in that issue today, and might start with a fresh prototype for a more solid form value storage.
Comment #4
jeroen.b commented@derhasi, any news on this?
Comment #5
jeroen.b commentedComment #6
derhasi commentedNot yet, I'm looking forward on working on it next week.
Comment #7
jeroen.b commentedAlso please check if this is still an issue after #2271845
Comment #8
seanbI can reproduce this issue the following way:
Everything goes as planned untill field_attach_form is called. After that I'm not sure where it goes wrong. I will investigate some more, but hopefully this helps to reproduce the issue.
*edit: Yeah, this is still an issue after #2271845
Comment #9
seanbIt looks like there are some references in the form state which are not updated after deleting a paragraph item or something. Like it looks for the field values in their old delta nr. I have no time left today, but will try to check again later.
Comment #10
seanbMaking it critical, since it can cause data loss.
Comment #11
derhasi commentedI will have a look at it today. We seam to still have some issues with this.
Comment #12
derhasi commented#2394313: Paragraphs data loss with Node Clone module may be related to this
Comment #13
jeroen.b commentedIn the D8 version I don't use $element directly for the entity, everything is in a $element['subform'] there, maybe we can base a fix on that?
The issue you mentioned is because of node clone and having a reference to the same paragraph item.
Comment #14
jeroen.b commented@seanB, I can't reproduce anymore after fixing #2410931.
Is it possible that it's already fixed or is there still some other issue with directly using $element?
Comment #15
jeroen.b commentedComment #16
derhasi commentedComment #17
manu manuHi,
It seems that I experience a problem related to this issue, in the context of nested Paragraphs, using the latest dev.
Given:
A node having a paragraph field
field_contentthat can embed acontainerparagraph bundle.The
containerparagraph bundle have afield_contentfield.The problem:
When editing the node and creating a
containerinfield_content, editing a field of this container will makeparagraphs_field_widget_form_build()use the node as host entity (from $element['#entity']) instead of the container bundle. Later, when extracting ids, the passed entity is not the right one:Some people doesn't have issues with nested paragraphs, so I may be wrong somewhere...
Comment #18
seanbI can confirm the issue in #17. This only happens when using nested paragraphs. I have sites where this is working fine, so it is probably not easy to reproduce this.
I guess this is related to https://www.drupal.org/node/2564327
Comment #19
eelkeblokWRT #17, this is not much more than a hunch, at this point, but I seem to have tracked this down to the i18n_field module. I have a very similar situation to #17 (identical stack trace), except that I have a paragraph field that is in my node as well as in a field collection in the node. The field instance info for the node type's field instance is overwritten at some point by the instance info for the field_collection's instance of the same field. This is causing entity_extract_ids() to choke down the line. I was interested to know whether people who are seeing this behaviour have i18n_field module enabled as well.
Comment #20
eelkeblokThis indeed seems to be the problem, at least for me. Please see #2685853: i18n_field does not correctly set form_state for nested fields for details. I'd be interested to learn whether this also solves #17. If not, you may want to investigate whether there are any other modules that are corrupting the information about the field in the form_state.
Comment #21
recrit commentedSee patch #85 on #2564327: Host entity problems (ajax errors / nested paragraphs / UI speed)
Comment #22
tylersamples commentedI can replicate this, it doesn't seem to be specific to the i18n_field module.
Structure I have:
Node -> Paragraph -> Paragraph -> Field collection
Somewhere around form_attach_field it's failing to retrieve the correct instance.
Comment #23
eelkeblokIt's conceivable other modules do something similar to i18n_field. It would be really interesting if you could debug further.
Comment #24
jstollerIn an effort to cleanup the Paragraphs issue queue I'm closing this ticket and marking it "outdated." If you find this is still a problem with the latest Paragraphs 7.x-1.x-dev release than feel free to reopen the issue.