Entity reference revision fields like Paragraph references will break with this module. They rely on the revision ID rather than the entity ID for the field values. When exporting a Paragraph entity, the correct revision ID is exported but after importing, the revision IDs are not maintained. They are sequential starting at 1. That means any imported entity using an entity reference revision field will be pointing to the incorrect paragraph entities.

CommentFileSizeAuthor
#6 exported_revision_ids-2989887-6.patch2.14 KBapugacescu
#4 Screenshot from 2018-08-03 16-33-35.png27.8 KBapugacescu

Comments

mstef created an issue. See original summary.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Status: Active » Postponed (maintainer needs more info)

We only rely on core's serialization api here.

So it depends on what entity_reference_revisions does for normalizing/denormalizing its field type.

Can you see if they have an issue in their queue tracking improvements to that?

andypost’s picture

andypost
he/him
Primary language Russian
commented

I'm using `dcer` to export nodes with paragraphs for a long time & remember no issues for last year at least

apugacescu’s picture

apugacescu commented
StatusFileSize
new Screenshot from 2018-08-03 16-33-35.png27.8 KB

Faced the same issue, using 8.4.7 core. Exported entities have id and revision_id/vid (depending on entity type) in json file but during import revisions are created sequentially so the relation between nodes and paragraphs are broken after import because revision id does not match.

This issue was not present in 8.3.

apugacescu’s picture

apugacescu commented
Status: Postponed (maintainer needs more info) » Needs work
apugacescu’s picture

apugacescu commented
Status: Needs work » Needs review
StatusFileSize
new exported_revision_ids-2989887-6.patch2.14 KB

After some investigation found out the following:
Entity's "newRevision" attribute "Boolean indicating whether a new revision should be created on save" defaults to TRUE (which is correct) but during deserialization process changes the value to FALSE. It is triggered by onChange event deep inside the stack here https://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/Entity/Cont.... This indeed should happen but not during deserialization process but during save process instead (which actually happens).
Now when "newRevision" attribute is FALSE the save process triggers setNewRevision method that removes existing value of the revision that was extracted from the exported content json which triggers the process of new revision generation (incremental value).

The problem that I see here is that the content is wrong state. It should have a revision id and newRevision should be TRUE in order to keep existing revision id from the exported file. Currently we are getting newRevision FALSE and a revision id that is removed and regenerated.

Attaching a patch that should fix this issue it might not be the most elegant solution but it worked in my case.

botanic_spark’s picture

botanic_spark commented

I was facing same issue on Drupal 8.4.7.
After applying the patch, paragraphs are exported fine.

lpeabody’s picture

lpeabody commented
Status: Needs review » Reviewed & tested by the community

Works for me. Thank you!

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

Thanks, the patch makes sense - but can we get a test for this?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Needs work » Closed (won't fix)

I've recently created the 2.0.x branch, see the project page on all the improvements in the 2.0.x branch. Testing that and providing feedback would be very welcome. The 1.x branch isn't actively maintained and won't receive new features anymore, so I'm closing this and other issues as won't fix.

2.0.x does not export or import ID fields and ERR composite fields like paragraphs are automatically embedded into a single file.