Problem/Motivation
At the moment, nested IEFs lose references when the lowest level entity is updated and using entity reference revisions, with revisioning turned on.
Steps to reproduce
1. Set up a nested IEF situation, with entity reference revisions, turning on revisioning and using the complex widget. For example Page referencing Article and Article referencing News. Both with Complex widget and both with revisioning turned on, unlimited cardinality on the Article->News reference.
2. Create a Page in which you create an Article inline and in which you create a News inline, and save -> all is fine.
3. Edit the Page in which edit the Article in which edit the News in which change the title. Hit Update on the News, Update on the Article and Save. -> Result: new revision of News is created but the reference from Article to News is lost.
Notes:
* It's possible that if you don't hit Update in the form, it doesn't break.
* The inside-out saving does help a bit for this #2721349: Nested inline entities must be saved in "inside-out" order but not completely.
* My attempt from https://www.drupal.org/project/inline_entity_form/issues/2721349#comment... fixes things partially it seems. You can also get a better understanding why this would happen. However, trying with 3 levels, this did not work for some reason but didn't get a chance to understand why (strange in any case).
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork inline_entity_form-3197037
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
geek-merlinComment #3
geek-merlinComment #4
upchuk commentedComment #5
geek-merlinThanks!
So this sounds like a nasty thing. Just a gut feeling, i guess 99% of ERR usage is Paragraphs, and i dug into ERR code, and quite a lot of paragraphs specific logic moved into ERR, so maybe this is really an ERR issue.
> * It's possible that if you don't hit Update in the form, it doesn't break.
OK, this is to be checked.
> * The inside-out saving does help a bit for this, but not completely.
Understanding what this changes might help here too.
> However, trying [that patch] with 3 levels, this did not work for some reason but didn't get a chance to understand why...
OK.
Let's proceed like this: We fix the inside-out thing, which supposedly will improve debuggability too. And then come back to this.
Comment #6
geek-merlinI'm further in debugging this convoluted mess, but it looks like we have some layers of bugs.
Comment #8
geek-merlinComment #9
geek-merlin> There was 1 error: ComplexWidgetRevisionsTest::testRevisionsAtDepth with data set #1 (true): The text "Level 3.1" was not found
Yay, this is exactly what we need.
Comment #10
geek-merlinOK, so...
- we have the test-only fail in #9
- test-plus-fix is green
so this is ready. 🎉
Notes
@Upchuk You can recognize your patch approach from #2721349-22: Nested inline entities must be saved in "inside-out" order here. If you see any issues, feel welcome to feedback, and we'll look at that in a followup issue (to get ahead more quickly).
TBH, at first i thought this approach is a bandaid for a deeper problem. But digging deeper, i'm quite sure there is none without changing ERR logic, which is out of scope here.
As of the tests: That this was not covered by tests was no issue of clicking the inner submit buttons. It was that the inner ref did not add new revisions, which gave me a tough time debugging as i did not even think of that possibility first. Now the test (which is excellently written legibility-wise!) covers both variants.
Comment #12
geek-merlinComment #13
geek-merlinComment #14
upchuk commented@geek-merlin,
So, I tested and this is a good start. I see it's basically my approach :)
IMO the PR could be cleaned up a bit for things like doc blocks, coding standards and I think the updater could be a service? Anyway, these are minor, I can make a patch for these. I conform this works also with 3 levels.
But we have more important problems.
On a fresh install it works. However, if the main node is translatable (Page from the description) AND the reference field from Page to Article is NOT translatable AND there is a moderation workflow on Page, we have the same problem. Took me a long time to reproduce. And turns out, if you then disable the workflow on the CT, it will still fail. So once enabled, it will fail even after disabling.
I have no idea why but the symptom is that when the form is submitted, the entire reference is gone from the entity that is found in the inline_entity_form form_state, so the updater no longer can compare the target_ids to update the reference with the saved revision.
Please let me know if you can reproduce.
Comment #15
upchuk commentedJust as an update, the content moderation part of the reproduction is finicky. Try with it and without it and see. On a different installation, it worked also with a workflow on it. But it may be a coincidence caused by something else. Super difficult to tell what is happening.
Comment #16
geek-merlinHuuu, adding multilingual & CM to the game is a completely new can of works. Let's go on in #3205669: EntityReferenceRevisions+Translation+ContentModeration in nested IEF loses Refs.
Comment #18
snable commentedHi, just a follow up on the issue.
I am curious why the error gets triggered based on the existence of the entity id.
If you e.g. prevent saving an entity in the first place for whatever reason, the entity won't get an id - but with the logic applied registerEntity will throw an error in ReferenceUpgrader.php:
And the Method is also triggered as a kind of "post" save method after the original save of the entity (which also might prevent an entity from being saved at all) in WidgetSubmit.php:
Comment #19
nils.destoop commentedIdd. This also seems the reason why I'm getting a fatal error when you submit the node form, without first saving the inline entity form.